Hi guys,
A bit late to the party (I'm technically on holidays this week), but...
"The best solution I have seen around the security question of new accounts
that haven't been used is to start with them disabled and then have the user
go to a kiosk machine which goes to a website where they have to identify
themselves with some key info from their application or "welcome" package
that is unique to them (hate to say it but like drivers license number or
social security number, etc) and then they go through some various screens
on the kiosk and at the end if they pass, their account gets activated and
set with a secure password that they specify. I actually have that listed on
a list of about 50 tools I want to build."
Joe's right on the money here, and we've actually got customers doing
exactly this.
The process goes something like this:
* HR says user should be provisioned. Day 1 of employment hasn't
happened yet; we want to be ready for it up front, since some steps
are manual and take time. The point raised earlier in the thread
about avoiding lost productivity is right on the money, especially
in larger organizations, which have a tendency to move slowly.
* Our new user is auto-provisioned to AD, Exchange, mainframe,
Unix, etc. All the new IDs are disabled. The initial password is
actually a long, random string, which is immediately discarded.
* The user's profile is populated into a self-service password reset
system, using some demographic data (SSN, DoB, etc. etc.).
* On day 1, the user shows up, or doesn't. If not, another HR-driven
process triggers cleanup.
* If the user did turn up, he can use his own (newly allocated and
delivered) PC to access a kiosk-mode web browser from the GINA prompt.
This is similar to Joe's idea, but a bunch of physical kiosks at
each location are not required -- a domain-level "secure kiosk
account," accessible from any workstation, is used for this purpose,
and for assisting users who forgot their Windows password.
* Our new user logs into the GINA with the SKA ID/password, which are
well known. This takes him to the only place he can really go -- a
hardened web browser directed at the password reset app, which
forces him to go through an enrollment process. This updates his Q&A
profile, so that we won't have to use the relatively weak demographic
data again.
* Our new user now gets to reset his own "forgotten" (actually random
and discarded) password to a known value. He can now login as himself.
Note that this process eliminates the need for default passwords, or
even for reasonable passwords that other people, such as the HR hiring
manager and system administrators, know.
It would be fairly simple to add steps to the process, such as getting
the user to read and accept the AUP and provide any ancillary data that
HR didn't pick up for some reason.
If and when you decide that's something you want to do and if you want some
help/sounding board to bounce that off of, please feel free to include me.
No need to ask again ;) I would however try to guide such a solution to use
something other than personalized information. Unique numbers are far
better and can be generated and communicated securely. There's no need for
localized personal information such as dl# or ssn.
I agree that (long) unique numbers are stronger than demographics,
but they have problems too: Providing unique numbers to pre-provisioned
users implies that something physical is delivered to the new users.
This is sometimes inconvenient, slow or even impossible in large, global
organizations. Moreover, users may lose the physical note with the
number on it, and/or forget the number you gave them. This triggers the
need for an out-of-band process, which will likely revert to
demographics. :-)
I hope this helps!
--
Idan Shoham
Chief Technology Officer
M-Tech Information Technology, Inc.
[EMAIL PROTECTED]
http://mtechIT.com
****************************************************************************
Sign-up for M-Tech's winter training sessions:
P-Synch: January 8--12, 2007 || ID-Synch: January 15--19, 2007
To register, please visit: http://mtechIT.com/education/
****************************************************************************
The information in this email is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
email by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying, distribution or any action taken or
omitted to be taken in reliance on it, is prohibited and may be unlawful.
****************************************************************************
On Wed, 27 Dec 2006, Al Mulnick wrote:
Yeah, I've seen that work as well Brian.
In fact joe, to this part:
On 12/27/06, Brian Desmond <[EMAIL PROTECTED]> wrote:
*The process I had come up with for a large org which never got
implemented (see committee) was to tie a process in with HR enrollment and
the new user would get a page with a token code type thing just key that
in someplace (e.g. kiosk) and you were good to go. The actual kiosk web
app is trivial to build just a matter of generalizing it to work with a
multitude of organizations. *
* *
*Thanks,*
*Brian Desmond*
[EMAIL PROTECTED]
* *
*c - 312.731.3132*
* *
*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *joe
*Sent:* Wednesday, December 27, 2006 2:37 PM
*To:* ActiveDir@mail.activedir.org
*Subject:* RE: [ActiveDir] Automatic user disable based on criteria
Ah I see where you are coming from now... I didn't question that at all
because the large accounts I tend to work on, it isn't something you would
question, a request comes in from somewhere and IT processes it, yet the
responsibility of cleaning it up resides with IT. Alternately you have a
heavily distributed management model, something I am not a huge fan of with
native rights as mentioned previously, and whomever is responsible for AD
as
a whole is the only one going through cleaning up. Granted seven days seems
agressive to me, but I have heard worse.. Plus I actually understand where
they are coming from. They don't want an activated ID with a default
password just hanging out there. The example Andrew gave is definitely a
good example from what I have seen as well.
The best solution I have seen around the security question of new accounts
that haven't been used is to start with them disabled and then have the
user
go to a kiosk machine which goes to a website where they have to identify
themselves with some key info from their application or "welcome" package
that is unique to them (hate to say it but like drivers license number or
social security number, etc) and then they go through some various screens
on the kiosk and at the end if they pass, their account gets activated and
set with a secure password that they specify. I actually have that listed
on
a list of about 50 tools I want to build.
For the simple case of disabling after 7 days... I would actually want
more info myself to make a decision as Exchange isn't taken into account at
all and the vast majority of AD's I see are running Exchange. When Exchange
is in the picture the go/no go decision is much more difficult because
there
is no realistic way to find out if a mailbox is truly being used. You can
usually prove it is being actively used but not the obverse which means you
tend to have to make even more assumptions about Exchange than an AD ID.
None of the AD attributes are of much help except the Exchange UAC value
and
that is usually enabled if the account is enabled. You can't base anything
on the MAPI attribute such as last logon, etc. You also can't base anything
off of whether or not the account is receiving or sending mail based on all
of the different uses a mailbox could have (for instance, maybe it is just
used as a calendar item for conference rooms). The best we have found to
date is to collect a variety of data points and then generate a list of
possibles which is handed over to a customer rep to determine which should
and shouldn't be removed.
Without Exchange, I think what we have is pretty good though. You may end
up having to recreate the account though. That is expected and
I specifically mentioned it.
I agree getting all groups on the same page would be nice, but the more
large companies I deal with the less realistic I feel this is as a generic
answer for them. Most of the large companies seem to be a complete mess
when
it comes to managing IT stuff in general and identity specifically. Smaller
companies tend to have a better shot at it because the realm of control is
usually wider although they tend to struggle with resource issues... They
may have the control they need but no resources to implement certain ideas.
In a larger org where you have the resources, it is unlikely any one person
has the span of control necessary to force the change and getting a group
of
managers from different areas of a company into a committee[1] to come to
agreement on something that changes their processes is near impossible
because the folks who want the changes don't have the budget to pay for the
other departments that have to change things. Only in times of crisis or
big
changes do these kinds of changes tend to happen with any regularity and
only if someone jumps up and makes themselves a target.
joe
[1] Committee - A group of men who individually can do nothing but as a
group decide that nothing can be done. - Fred Allen
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
------------------------------
*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *Al Mulnick
*Sent:* Tuesday, December 26, 2006 12:06 PM
*To:* ActiveDir@mail.activedir.org
*Subject:* Re: [ActiveDir] Automatic user disable based on criteria
All of this assumes that the process doesn't need to be adjusted - I keep
asking myself why a process exists to allow for the creation of an account
that isn't used? That's really the root of this. After that, I have to
wonder why the various processes aren't coordinated amongst themselves such
as password resets, forgotten passwords, new account creation and others
all
being aware of one another?
I think your example helps to add more information that can be used in the
decision and I agree that if you're going to base the decision on the idea
of when it was created and assume that because the password was changed [x]
amount of time after the creation of the item but NOT less than [y] amount
of time has elapsed, that it's going to be fairly reasonable to assume that
the helpdesk (or?) has intervened and you should consider revisions to your
hiring processes.
I disagree that this is enough information to make me happy though :)
I think it's a fairly good assumption, but I would much prefer to loop in
the process and thinking described in a separate thread related to helpdesk
resetting passwords (auditing, web pages, other systems, etc) and use that
information as a flag in an account removal process. It's a sure thing
that
if the helpdesk hasn't reset the password since it was created that the
account wasn't used if the password also hasn't been set, right? You have
a
week so it's not like this needs to be real-time. It could, but doesn't
have to be.
Happy New Year to you and the others as well*
[*] Unless this isn't the New Year for you, in which case, have a great
day!
On 12/24/06, *joe* <[EMAIL PROTECTED]> wrote:
I didn't read the whole chain of responses, I was just skimming and saw
these questions
"Hey joe, is there a way to see replication meta data using adfind? ;-)
If yes, I could take a peek at originating date/time for attributes."
Yes it can show you the metadata from AD (assuming K3+) and that metadata
does indeed contain originating write into.
Now that I have read it... To solve the specific issue that I read; find
enabled users who haven't changed their passwords and logged in the period
defined, you can use the metadata to help with that decision. Obviously
having DFL2 would help as well. Neither in and of themselves I think would
be authoritative on their own except in specific cases.
The problem with DFL2 and lastLogonTimeStamp is that not everything sets
that value. Try a simple LDAP bind sometime, it doesn't update lastLogon so
it in turn doesn't update lastLogonTimeStamp. It will, however, update it
if
a bad auth attempt occurred prior. I never bugged that as I assume it is by
design as it is very specific and it helps cut the overhead of the auth
attempts which the simple bind is supposed to be helping with. That way
apps
that do a ton of simple binds don't cause a ton of writes to a DC.
So how would this be done? Well obviously you can't query the metadata, it
is constructed. So you need a query to give you an initial roundabout set
to
work with that you can test further. I would do something like
(&(samaccounttype=805306368)(pwdlastset=0)(whencreated<=7 days).
(&(samaccounttype=805306368)(pwdlastset=0)(whencreated>=[date 7 days
ago])(!(useraccountcontrol:AND:2))
Obviously that last field would need to be generated at the time of the
query being run. So now you have a list of possibles... You could give up
here and reasonably assume that everything is fine and take on the
resulting
help desk calls. I wouldn't have much if any issue with this method unless
it had already been proven there was too much collateral damage. I would
have to decide whether I wanted to be more concerned about the method or
the
fact that new people need to be reset again so soon which likely indicates
a
process issue or overly agressive password policy or underly agressive
hiring policy.
So you decide you need to be more fine tuned... So you look at metadata.
Right off if the unicodePwd version is 1 then the password has never been
changed and that is as authoritative as it is going to get. You definitely
know this person has NEVER changed that password. However, the obverse is
not true, you cannot assume that if the version is higher than 1 that the
password HAS been changed. The password versioning can vary based on the
creation method. Here is the metadata from two accounts created in three
different ways:
[Sun 12/24/2006 11:42:20.45]
G:\>repadmin /showmeta CN=al-testuser0,CN=Users,DC=test,DC=loc r2dc1
31 entries.
Loc.USN Originating DC Org.USN Org.Time/Date
Ver Attribute
======= =============== =========
============= === =========
441322 Default-First-Site-Name\R2DC2 406847 2006-12-24
10:53:00 1 objectClass
441322 Default-First-Site-Name\R2DC1 441322 2006-12-24
10:53:01 1 cn
441322 Default-First-Site-Name\R2DC2 406848 2006-12-24
10:53:00 1 description
441322 Default-First-Site-Name\R2DC2 406847 2006-12-24
10:53:00 1 instanceType
441322 Default-First-Site-Name\R2DC2 406847 2006-12-24
10:53:00 1 whenCreated
441322 Default-First-Site-Name\R2DC2 406849 2006-12-24
10:53:00 2 displayName
441322 Default-First-Site-Name\R2DC2 406847 2006-12-24
10:53:00 1 nTSecurityDescriptor
441322 Default-First-Site-Name\R2DC2 406847 2006-12-24
10:53:00 1 name
441322 Default-First-Site-Name\R2DC2 406849 2006-12-24
10:53:00 3 userAccountControl
441322 Default-First-Site-Name\R2DC2 406848 2006-12-24
10:53:00 1 codePage
441322 Default-First-Site-Name\R2DC2 406848 2006-12-24
10:53:00 1 countryCode
441322 Default-First-Site-Name\R2DC2 406848 2006-12-24
10:53:00 1 homeDirectory
441322 Default-First-Site-Name\R2DC2 406848 2006-12-24
10:53:00 1 homeDrive
441322 Default-First-Site-Name\R2DC2 406849 2006-12-24
10:53:00 2 dBCSPwd
441322 Default-First-Site-Name\R2DC2 406848 2006-12-24
10:53:00 1 scriptPath
441322 Default-First-Site-Name\R2DC2 406848 2006-12-24
10:53:00 1 logonHours
441322 Default-First-Site-Name\R2DC2 406848 2006-12-24
10:53:00 1 userWorkstations
441322 Default-First-Site-Name\R2DC2 406849 2006-12-24
10:53:00 2 unicodePwd
441322 Default-First-Site-Name\R2DC2 406849 2006-12-24
10:53:00 2 ntPwdHistory
441322 Default-First-Site-Name\R2DC2 406849 2006-12-24
10:53:00 2 pwdLastSet
441322 Default-First-Site-Name\R2DC2 406848 2006-12-24
10:53:00 1 primaryGroupID
441322 Default-First-Site-Name\R2DC2 406850 2006-12-24
10:53:00 1 supplementalCredentials
441322 Default-First-Site-Name\R2DC2 406848 2006-12-24
10:53:00 1 userParameters
441322 Default-First-Site-Name\R2DC2 406848 2006-12-24
10:53:00 1 profilePath
441322 Default-First-Site-Name\R2DC2 406847 2006-12-24
10:53:00 1 objectSid
441322 Default-First-Site-Name\R2DC2 406848 2006-12-24
10:53:00 1 comment
441322 Default-First-Site-Name\R2DC2 406849 2006-12-24
10:53:00 2 accountExpires
441322 Default-First-Site-Name\R2DC2 406849 2006-12-24
10:53:00 2 lmPwdHistory
441322 Default-First-Site-Name\R2DC2 406847 2006-12-24
10:53:00 1 sAMAccountName
441322 Default-First-Site-Name\R2DC2 406847 2006-12-24
10:53:00 1 sAMAccountType
441322 Default-First-Site-Name\R2DC2 406847 2006-12-24
10:53:00 1 objectCategory
0 entries.
Type Attribute Last Mod Time
Originating DC Loc.USN Org.USN Ver
======= ============ =============
================= ======= ======= ===
Distinguished Name
=============================
[Sun 12/24/2006 11:42:28.25]
G:\>repadmin /showmeta CN=al-testuser1,CN=Users,DC=test,DC=loc r2dc1
22 entries.
Loc.USN Originating DC Org.USN Org.Time/Date
Ver Attribute
======= =============== =========
============= === =========
441326 Default-First-Site-Name\R2DC2 406856 2006-12-24
10:53:53 1 objectClass
441326 Default-First-Site-Name\R2DC1 441326 2006-12-24
10:53:54 1 cn
441326 Default-First-Site-Name\R2DC2 406856 2006-12-24
10:53:53 1 instanceType
441326 Default-First-Site-Name\R2DC2 406856 2006-12-24
10:53:53 1 whenCreated
441326 Default-First-Site-Name\R2DC2 406856 2006-12-24
10:53:53 1 nTSecurityDescriptor
441326 Default-First-Site-Name\R2DC2 406856 2006-12-24
10:53:53 1 name
441326 Default-First-Site-Name\R2DC2 406856 2006-12-24
10:53:53 1 userAccountControl
441326 Default-First-Site-Name\R2DC2 406857 2006-12-24
10:53:53 1 codePage
441326 Default-First-Site-Name\R2DC2 406857 2006-12-24
10:53:53 1 countryCode
441326 Default-First-Site-Name\R2DC2 406857 2006-12-24
10:53:53 1 dBCSPwd
441326 Default-First-Site-Name\R2DC2 406857 2006-12-24
10:53:53 1 logonHours
441326 Default-First-Site-Name\R2DC2 406857 2006-12-24
10:53:53 1 unicodePwd
441326 Default-First-Site-Name\R2DC2 406857 2006-12-24
10:53:53 1 ntPwdHistory
441326 Default-First-Site-Name\R2DC2 406857 2006-12-24
10:53:53 1 pwdLastSet
441326 Default-First-Site-Name\R2DC2 406857 2006-12-24
10:53:53 1 primaryGroupID
441326 Default-First-Site-Name\R2DC2 406858 2006-12-24
10:53:53 1 supplementalCredentials
441326 Default-First-Site-Name\R2DC2 406856 2006-12-24
10:53:53 1 objectSid
441326 Default-First-Site-Name\R2DC2 406857 2006-12-24
10:53:53 1 accountExpires
441326 Default-First-Site-Name\R2DC2 406857 2006-12-24
10:53:53 1 lmPwdHistory
441326 Default-First-Site-Name\R2DC2 406856 2006-12-24
10:53:53 1 sAMAccountName
441326 Default-First-Site-Name\R2DC2 406856 2006-12-24
10:53:53 1 sAMAccountType
441326 Default-First-Site-Name\R2DC2 406856 2006-12-24
10:53:53 1 objectCategory
0 entries.
Type Attribute Last Mod Time
Originating DC Loc.USN Org.USN Ver
======= ============ =============
================= ======= ======= ===
Distinguished Name
=============================
[Sun 12/24/2006 11:42:31.05]
G:\>repadmin /showmeta CN=al-testuser2,CN=Users,DC=test,DC=loc r2dc1
24 entries.
Loc.USN Originating DC Org.USN Org.Time/Date
Ver Attribute
======= =============== =========
============= === =========
441354 Default-First-Site-Name\R2DC2 406894 2006-12-24
11:26:14 1 objectClass
441354 Default-First-Site-Name\R2DC1 441354 2006-12-24
11:26:15 1 cn
441354 Default-First-Site-Name\R2DC2 406894 2006-12-24
11:26:14 1 instanceType
441354 Default-First-Site-Name\R2DC2 406894 2006-12-24
11:26:14 1 whenCreated
441354 Default-First-Site-Name\R2DC2 406894 2006-12-24
11:26:14 1 displayName
441354 Default-First-Site-Name\R2DC2 406894 2006-12-24
11:26:14 1 nTSecurityDescriptor
441354 Default-First-Site-Name\R2DC2 406894 2006-12-24
11:26:14 1 name
441354 Default-First-Site-Name\R2DC2 406900 2006-12-24
11:26:15 4 userAccountControl
441354 Default-First-Site-Name\R2DC2 406895 2006-12-24
11:26:14 1 codePage
441354 Default-First-Site-Name\R2DC2 406895 2006-12-24
11:26:14 1 countryCode
441354 Default-First-Site-Name\R2DC2 406896 2006-12-24
11:26:15 2 dBCSPwd
441354 Default-First-Site-Name\R2DC2 406895 2006-12-24
11:26:14 1 logonHours
441354 Default-First-Site-Name\R2DC2 406896 2006-12-24
11:26:15 2 unicodePwd
441354 Default-First-Site-Name\R2DC2 406896 2006-12-24
11:26:15 2 ntPwdHistory
441354 Default-First-Site-Name\R2DC2 406898 2006-12-24
11:26:15 3 pwdLastSet
441354 Default-First-Site-Name\R2DC2 406895 2006-12-24
11:26:14 1 primaryGroupID
441354 Default-First-Site-Name\R2DC2 406897 2006-12-24
11:26:15 1 supplementalCredentials
441354 Default-First-Site-Name\R2DC2 406894 2006-12-24
11:26:14 1 objectSid
441354 Default-First-Site-Name\R2DC2 406895 2006-12-24
11:26:14 1 accountExpires
441354 Default-First-Site-Name\R2DC2 406896 2006-12-24
11:26:15 2 lmPwdHistory
441354 Default-First-Site-Name\R2DC2 406894 2006-12-24
11:26:14 1 sAMAccountName
441354 Default-First-Site-Name\R2DC2 406894 2006-12-24
11:26:14 1 sAMAccountType
441354 Default-First-Site-Name\R2DC2 406894 2006-12-24
11:26:14 1 userPrincipalName
441354 Default-First-Site-Name\R2DC2 406894 2006-12-24
11:26:14 1 objectCategory
0 entries.
Type Attribute Last Mod Time
Originating DC Loc.USN Org.USN Ver
======= ============ =============
================= ======= ======= ===
Distinguished Name
=============================
One was created with NET USER, one with ADUC, and one with AdMod. The
accounts aren't configured identically but they are close enough for what
we
are talking about her. You will note that unicodePwd value is 1 on the
AdMod
example and 2 for the others. This can vary based on whatever tool is used
and how it handles various items. So obviously the version number is out
the
window of something to look at because we are doing all of this to try and
reduce assumptions. So looking at all of that data, the first thing that
sticks out to me to use would be to look at the date/time stamp between
objectCategory which cannot be changed and unicodePwd which is the value we
care about. I believe you can safely assume here that if the values are
within seconds of each other the user has not had an opportunity to set
their own password yet.
Helpful?
Merry Christmas to everyone who leans that way, Happy Holidays to everyone
who doesn't.
take care and let's look forward to a good and profitable 2007,
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
------------------------------
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
*On Behalf Of *Al Mulnick
*Sent:* Sunday, December 24, 2006 9:12 AM
*To:* ActiveDir@mail.activedir.org
*Subject:* Re: [ActiveDir] Automatic user disable based on criteria
I have the distinct impression that Kamlesh is trying to solve a layer 8
problem with lower layer components. :)
I think it's very interesting that those attributes can show when it was
last changed, but I have to ask: will that show the difference between what
was changed? Is it possible to differentiate between phone number updates
and the helpdesk action described?
I haven't used those attributes to make decisions on in the past, so bear
with me but a quick lookup indicates that those values show that an object
was updated and who updated it. Is that going to be enough information to
make an automated decision? Or do you need some other information to
absolutely identify good from not-so-good targets?
I'm curious if this is something that high-tech should be used to solve
vs. using a different process/low-tech solution.
-ajm
On 12/23/06, *joe* <[EMAIL PROTECTED]> wrote:
Yes actually adfind can show you metadata... Look at the attributes
msDS-ReplAttributeMetaData
msDS-ReplValueMetaData
I actually have a DCR for AdFind (submitted by me which means it for sure
will get done) that will display that info in a better way than that XML
format they use. When it does, it will also use the binary format of the
attribute so it won't be so slow nor require as much network bandwidth.
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
------------------------------
*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *Kamlesh Parmar
*Sent:* Monday, December 18, 2006 12:19 PM
*To:* ActiveDir@mail.activedir.org
*Subject:* [ActiveDir] Automatic user disable based on criteria
Hi All,
DFL & FFL : Win2k-Native
DCs : Win2k3-SP1
User accounts are automatically provisioned as enabled with "Change
Password at Next logon". And management wants to disable new accounts which
have not logged into domain within next 7 days of creation. And they want
it
to happen automatically.
I have problem at hand as I can't use LastLogonTimeStamp as DFL is not
supportive. I can't connect to each DC and search for lastlogon as number
of
DCs are too large, can't go by "whenchanged", as that is generic attribute,
which could get changed for any other attribute also.
Any other attribute would help me?
Currently LDAP filter checks for account created on specific day (say
current day - 7) and whose "Change Password at next logon" is still ticked
i.e. pwdlastset=0
But this doesn't take care of scenario, where users are created on that
same day (current - 7) and logged into network, changed their password,
but around the time of running script, had forgotten password and helpdesk
had resetted their password and set "Change Password at next logon"
I hope I am not confusing you all. :-)
I know, simple solution would be to change criteria to say 15 days, raise
DFL and use LLTS, but I am taking this as a scripting challenge at
Win2k-native DFL.
Hey joe, is there a way to see replication meta data using adfind? ;-)
If yes, I could take a peek at originating date/time for attributes.
--
Kamlesh
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You teach best what you most need to learn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
