Karsten- The first thing you want to do is give the rights to a group. Never delegate something to an individual user. So, lets create a group called Telephone Editors. Add your user into there.
Next, in AD Users & Computers, goto View>Advanced Features. Then, pull up the properties of the top level OU that contains all the users you want to delegate telephoneNumber update authority over. You could also do this at the domain level. Goto the Security tab, click advanced, and then hit add. Punch in Telephone Managers. On the properties tab, select Apply onto User Objects (from the dropdown), then, scroll down and find telephoneNumber. Tick the write checkbox. You should be good to go. Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:ActiveDir- > [EMAIL PROTECTED] On Behalf Of Karsten Aarhus > Sent: Thursday, February 02, 2006 5:39 AM > To: ActiveDir@mail.activedir.org > Subject: [ActiveDir] Need to update my list > > Dear all, > > How do I give an user on my domain rigths so she can update my Active > Directory list? > > I need to update all the phone numbers on my users. > > Venlig hilsen/Best regards > Astralis A/S > > Karsten Aarhus > Network-Administrator > Direkte +45 2725 1680 > Fax +45 7678 5502 > Mobil +45 2725 1680 > www.astralis.dk > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, > CPA aka Ebitz - SBS Rocks [MVP] > Sent: Thursday, February 02, 2006 5:04 AM > To: ActiveDir@mail.activedir.org > Subject: Re: [ActiveDir] User Account Lifecyle -- Best Practices > > Dr. Jesper Johansson > Steve Riley > > Up there with the Gibson titled "rogue developers" you know..... > > "Protecting your Windows Network" > > http://www.microsoft.com/technet/community/columns/secmgmt/sm1204.mspx > > Specifically > http://www.microsoft.com/technet/community/columns/secmgmt/sm1204.mspx#E > CAA > > http://www.protectyourwindowsnetwork.com/listening_room.htm > > Al Mulnick wrote: > > > Dr J? Irving? > > > > Riley = you mean Steve of the Northwest Riley Clan? Or somebody else? > > > > > I can say there are others that disagree with the idea of not having > > account lockout settings (assuming that's what was exactly said and > > not knowing the context) as well, because that option exists in the > > products. Somebody somewhere thinks it's of value. I happen to be one > > > that finds value in being able to lockout an account after a certain > > number of bad attempts. I'm also a person that believes that the > > account should become usable again after a predefined amount of time > > without human intervention. Why? Because people make mistakes. That > > > shouldn't cost valuable helpdesk time. Besides, the idea is to > > prevent automated attacks, not access to the system for normal user > > usage patterns. > > > > I have to say Susan, it's an interesting perspective that you bring. > > I believe that something that acts as a guideline vs. a checklist has > > value however. I don't see this as something that would be a > > checklist. I'm not a beancounter (although I've played one on the > > internet a few times) but I loathe doing things because somebody else > > thought it was a good idea. I need more information than that. A > > guide is sometimes helpful in doing that because if nothing else it > > helps to focus my thoughts. I use some of the books that are out > > there that way as well. Some of the books are better suited to help me > > > get that glass off the top shelf though. > > > > Interesting. > > > > > > > > On 2/1/06, *Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]* > > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > > > The problem with some of this is that books become stale...and > what is > > "best practices" today is not tomorrow with regulation and law > > changes. > > > > Then my pet peeve is that I don't believe that you can have one > best > > practice. And as a beancounter who's industry and profession wrote > the > > book on "follow the checklist as that's the way to do things" do I > > need > > to remind folks of the Enron case going on? > > > > This little SBSer thinks that best practices should be a > discussion > > item...not a checklist to follow. And it's my opinion that too > many > > times we check the box and don't think. But then again I can say > that > > because small firms have less politics than big ones. > > > > Example of a recommendation that I disagree with ... Dr. J and > > Riley say > > all the time that they don't recomment account lockout settings as > > it's > > a $75 help desk call. In SBSland.. it's never been an issue and > > puts a > > smidge more protection given that we tend have less layers. > > > > Some of these decision tree kind of stuff is also discussed in the > MS > > pdf "Threats and Countermeasures". But even then you have to > > decide what > > the risk is for your firm. > > > > In my own firm, short term employees, I blew them off ages ago, > long > > term employees I kept the accounts around, employees that had an > HR > > problem... that mailbox is still sitting on my server (yeah I > > should pst > > park it but it's easier just to disable it and leave it there). > > > > To me these policies need to be compared with what HR issues there > are > > with this terminated employee, in fact we had discussion in a SANS > > course that you may even want to image his/her workstation and > > leave it > > intact for forensic purposes. > > > > > > [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> wrote: > > > > > Well they sure don't teach this in college courses! A list of > > > questions to help define the scope of account management would > > be very > > > useful. You could then answer the questions with the pros and > > cons of > > > the various solutions. For example, address the Account Lockout > > > policies and then answer with the options to lock out and never > > > unlock, lock out and unlock after a specific time period, or not > > lock > > > out at all. All three are options but it would be great to have > > a book > > > that puts them all in one place with the pros/cons listed so > people > > > can make an informed decision and pick the option that is best > for > > > their situation. Tis better to give options and let someone make > > their > > > own decisions then to make the decision for them and get blamed > > for it > > > later down the road. > > > > > > ------------------------------------------------------------------------ > > > *From:* [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > [mailto:[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>] *On Behalf Of *Al > Mulnick > > > *Sent:* Wednesday, February 01, 2006 11:00 AM > > > *To:* ActiveDir@mail.activedir.org > > <mailto:ActiveDir@mail.activedir.org> > > > *Subject:* Re: [ActiveDir] User Account Lifecyle -- Best > Practices > > > > > > There are several schools of thought on this concept. There are > > > websites regarding identity management but I'm not sure it's > what > > > you're looking for. The idea of identity management is something > > that > > > is inherent in any networked or even standalone system that has > a > > > computer. Your ATM, Television contract, Phone Service, and > other > > > identities are all included in the same concept. I have not seen > > > anything specifically around this area of the concept, but I > think > > > that's more or less because it's so inherent in the ownership of > the > > > system that most people haven't really stopped to consider the > > pieces > > > that make up the whole. > > > Do you think an article is warranted in this case? Or should it > be > > > book length? What would you want to see different from what the > > myriad > > > of vendors put out there (vendors such as Microsoft, IBM, Cisco, > > > Abridean, etc.)? > > > I'm curious what the thinking is here and how much of a need > there > > > really is for this type of discussion. I know that Tony has been > > after > > > folks to blog some items and I know that Jorge did blog some of > > this. > > > But if you think more is needed beyond what Jorge did, I'd be > > > interested to know. I'd also bet that Jorge might be writing as > we > > > speak :) > > > > > > On 2/1/06, [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > <mailto:[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>>* < > > > [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > <mailto:[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>>> wrote: > > > > > > Is there possibly a book or website that might contain more > > > in-depth documentation on this subject? > > > > > > > > > ------------------------------------------------------------------------ > > > *From:* [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > <mailto:[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> [mailto: > > > [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > <mailto:[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>>] *On Behalf Of > > > [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> > > > *Sent:* Wednesday, February 01, 2006 3:37 AM > > > *To:* ActiveDir@mail.activedir.org > > <mailto:ActiveDir@mail.activedir.org> > > > <mailto:ActiveDir@mail.activedir.org > > <mailto:ActiveDir@mail.activedir.org>> > > > *Subject:* RE: [ActiveDir] User Account Lifecyle -- Best > > Practices > > > > > > Comments inline. > > > > > > First, thanks for the very thoughtful responses. Al, I > > appreciate > > > the "business requirements" concept. Unfortunately, around > here, > > > no one even thinks about this at all. I need to lead them in > > this > > > direction. So, given that a business process needs to be > > developed... > > > > > > Questions: > > > > > > - Can you help me tease out the pros and cons of: disable > (Jorge > > > and Al), expire (Al), or rename (Neil)? > > > [Neil Ruston] I prefer the rename rather than move etc since > (as > > > you state below) if the user needs to be 'reanimated' it may > > prove > > > difficult to configure him/her back to their original state. > I > > > have seen many a user 'leave' only to re-join the firm > within > > > weeks or months, or to not actually leave at all. Naturally, > you > > > need to take your lead from HR, but they can sometimes 'jump > > the > > > gun' :) I therefore prefer to rename and disable. > > > > > > - What is the point of removing a disabled/expired/renamed > > account > > > from Security Groups? If you need to re-enable the user, how > > will > > > you know what groups to put it in? And, isn't the account > > going to > > > be deleted (and therefore removed from the groups) anyway? > > > [Neil Ruston] See above comment. > > > > > > - Do any of you push the archived data off to other media > (like > > > DVD or tape)? > > > [Neil Ruston] User data should be backed up regularly > > anyway, so I > > > have not encountered a need to perform additional archives. > > > > > > Thanks again. > > > > > > -- nme > > > > > > > > > ------------------------------------------------------------------------ > > > > > > *From:* Al Mulnick [mailto: [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > <mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>] > > > *Sent:* Tuesday, January 31, 2006 6:23 AM > > > *To:* ActiveDir@mail.activedir.org > > <mailto:ActiveDir@mail.activedir.org> > > > <mailto: ActiveDir@mail.activedir.org > > <mailto:ActiveDir@mail.activedir.org>> > > > *Subject:* Re: [ActiveDir] User Account Lifecyle -- Best > > Practices > > > > > > Noah, I think by this point you can see that answers vary. > The > > > variables are the business requirements. > > > > > > An organization I did similar for looked at this as account > > > lifecycle management. 'Cradle to grave process.' > > > > > > Similar to the other posts, I helped define a process and > then > > > semi-automate it. The process definition is the important > part. > > > Being able to reconstruct the user object is the second most > > > important after that. Being able to automate it was the > third > > > priority because it was felt that fewer mistakes would be > > made, it > > > would require less effort to be expended, and it would be a > > > consistent process. > > > > > > In that environment, the process all started with an > > authoritative > > > notification of expiry. From there, the accounts were > > removed from > > > groups, moved to a new OU, marked with the deletion date, > > > disabled, etc. Everything that was done was logged in such a > > way > > > that it was easy to put this back with a minimal of effort > and > > > with audit capability in mind. No task was done without > logging > > > because of the compliance requirements surrounding the > > company's > > > business. > > > > > > This is a repetitive task and should be automated as much as > > > possible. How exactly you decide to do this is more a > > question for > > > your business leaders. Automating it is something you can > > either > > > do or not do, but once it's a defined process I see no > reason to > > > manually do anything in this situation. > > > > > > Additionally, I've always broken the whole lifecycle into > > several > > > parts: > > > > > > 1) provisioning (cradle) > > > > > > 2) De-provisioning (grave) > > > > > > 3) modifications (all that stuff in between) > > > > > > Automating provisioning of a new account is something that > > should > > > be automated. Automating removal of accounts should also be > > > automated in my opinion. Whenever possible, modifications > should > > > be semi-automated so you can capture what tasks were > performed > > > with a minimal of effort on the part of the administration > team. > > > In a perfect world, it should be so routine and easy that > either > > > the user can do it or my least trained and experienced staff > > > member can do it without error. That just about screams > > automation > > > to me. > > > > > > Start by defining the process requirements. Does your > company > > > require that the account be immediately unable to be > effective? > > > Expiring the account alone has some drawbacks in terms of > time. > > > Disabling has some other trade-offs. But removing the user's > > > ability to be used immediately upon notification is a > security > > > best practice. Archival depends on your company needs, but > it's > > > typically something that you want to have happen after a > decent > > > amount of time. Why? Because users tend to leave and come > back. > > > Similar to backups, you want to reduce the amount of time to > > > perform a restoration of any kind. This is no different. > > Tune the > > > process to accomdate the way your organization works and > you'll > > > save yourself a lot of time. > > > > > > My 0.04 (USD) worth anyway, > > > > > > Al > > > > > > On 1/31/06, [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > <mailto:[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>>* <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > <mailto: [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>>> wrote: > > > > > > Just my 2 penneth, but I have found that a rename of the > user > > > rather than a user move can work better. > > > > > > If the user is moved and then needs to be moved back to the > > > original location, you may encounter issues without a record > of > > > their original OU. > > > > > > Consider adding a suffix to the user name - e.g. > > > bloggsj_left_31012006 (I've used ddmmyyyy but of course > > mmddyyyy > > > is acceptable too :) > > > > > > neil > > > > > > > > > ------------------------------------------------------------------------ > > > > > > *From:* [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > <mailto:[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> [mailto: > > > [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > <mailto:[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>>] *On Behalf Of > > > *Almeida Pinto, Jorge de > > > *Sent:* 31 January 2006 09:37 > > > *To:* ActiveDir@mail.activedir.org > > <mailto:ActiveDir@mail.activedir.org> > > > <mailto:ActiveDir@mail.activedir.org > > <mailto:ActiveDir@mail.activedir.org>> > > > *Subject:* RE: [ActiveDir] User Account Lifecyle -- Best > > Practices > > > > > > Hi, > > > > > > I wrote the following a while ago... See if you can use the > > procedure > > > > > > What to do with user accounts that are or not mailbox > > enabled when > > > the corresponding user(s) leave(s) the company. For that and > > > without buying a full blown solution you can create tooling > in a > > > simple way if the following process is sufficient for you. > > > > > > IT IS A 5 STEP PROCESS: > > > (1) Be sure to receive some notification a user has left the > > company > > > (2) Move its user account to a special de-provisioning OU > > (manually) > > > (3) Schedule a script to run regularly (dayly or weekly or > > > whatever is good for you) to disable AD enabled user > > accounts in > > > the de-provisioning OU and if the account is mailbox enabled > to > > > add the "Associated External Account" permission to SELF. > Also > > > generate and set a difficult password (be carefull with > > > certificates if you use them for encryption!) > > > (4) Schedule a script to run regularly (dayly or weekly or > > > whatever is good for you) to check the de-provisioning OU > for > > > disabled user accounts that have been unused for a certain > > > (inactive) period (e.g. 90 days). In a W2K3 domain with > Domain > > > Functional Level 'Windows Server 2003' you can use the > > > 'lastLogonTimestamp' attribute that determines the last time > a > > > user logged on. In a W2K domain or W2K3 domain with Domain > > > Functional Level 'Windows Server 2000 native' or lower you > > can use > > > the 'lastLogon' attribute which is less accurate, but that > > will do. > > > If user accounts are found that meet the prerequisites > (disabled > > > and exceed a certain inactive period): > > > * Create a directory for the user in some "Archive Location" > > (the > > > archive location is a location where the user's stuff will > be > > > copied to, backup for a certain time and after some other > period > > > the user's stuff is removed) > > > * Extract all populated attibutes of the user account to the > > > user's archive location (using LDIFDE) > > > * Check if a home directory exists (read attribute and check > > > location) and MOVE it to the user's archive location > > > * Check if a profile directory exists (read attribute and > check > > > location) and MOVE it to the user's archive location > > > * Check if a TS home directory exists (read attribute and > check > > > location) and MOVE it to the user's archive location > > > * Check if a TS profile directory exists (read attribute and > > check > > > location) and MOVE it to the user's archive location > > > * Exmerge the mailbox into a PST in the user's archive > location > > > (be carefull with large PST sizes!!! e.g. > 2GB)( > > > > > > http://support.microsoft.com/default.aspx?scid=kb;en-us;830336)(http://s > upport.microsoft.com/default.aspx?scid=kb;en-us;823176 > > > <http://support.microsoft.com/default.aspx?scid=kb;en-us;830336%29%28htt > p://support.microsoft.com/default.aspx?scid=kb;en-us;823176> > > > < > > > http://support.microsoft.com/default.aspx?scid=kb;en-us;830336%29%28http > ://support.microsoft.com/default.aspx?scid=kb;en-us;823176>) > > > (5) Schedule a script to run regularly (dayly or weekly or > > > whatever is good for you) to check the all user's archive > > > locations to see which exceed the archiving period for > backup ( > > > e.g. 60 days). For this compare the folder creation date > > with the > > > current date. If a user archive location is found and it is > > older > > > than the current date minus the minimum required archiving > > period > > > for backup, delete the folder > > > > > > TOOLS USED: > > > * ADModcmd.exe and others from (ADModify.NET) ( > > > > > > http://www.gotdotnet.com/workspaces/workspace.aspx?id=f5cbbfa9-e46b-4a7a > -8ed8-3e44523f32e2) > > > * Robocopy.exe (tested with: v5.1.1.1010) (W2K3 Resource > Kit) ( > > > > > > http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4 > ae7-96ee-b18c4790cffd&displaylang=en > > > <http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff- > 4ae7-96ee-b18c4790cffd&displaylang=en> > > > > > > <http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff- > 4ae7-96ee-b18c4790cffd&displaylang=en > > > <http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff- > 4ae7-96ee-b18c4790cffd&displaylang=en>>) > > > * ExMerge.exe (tested with: v6.5.7529.0) ( > > > > > > http://www.microsoft.com/downloads/details.aspx?FamilyID=429163EC-DCDF-4 > 7DC-96DA-1C12D67327D5&displaylang=en > > > <http://www.microsoft.com/downloads/details.aspx?FamilyID=429163EC-DCDF- > 47DC-96DA-1C12D67327D5&displaylang=en> > > > > > > <http://www.microsoft.com/downloads/details.aspx?FamilyID=429163EC-DCDF- > 47DC-96DA-1C12D67327D5&displaylang=en > > > <http://www.microsoft.com/downloads/details.aspx?FamilyID=429163EC-DCDF- > 47DC-96DA-1C12D67327D5&displaylang=en>>) > > > > > > > > > cheers, > > > > > > Jorge > > > > > > > > > ------------------------------------------------------------------------ > > > > > > *From:* [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > <mailto:[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> on behalf of Noah > Eiger > > > *Sent:* Tue 2006-01-31 04:00 > > > *To:* ActiveDir@mail.activedir.org > > <mailto:ActiveDir@mail.activedir.org> > > > <mailto:ActiveDir@mail.activedir.org > > <mailto:ActiveDir@mail.activedir.org>> > > > *Subject:* [ActiveDir] User Account Lifecyle -- Best > Practices > > > > > > Hi - > > > > > > Can someone recommend or point me to best practices for user > > > account management? I guess that in large organizations this > is > > > either automated or some junior tech jockey is assigned to > > handle > > > this full time. In smaller organizations, what is on the > > checklist > > > when a user leaves? Do you disable or expire the account? > Does > > > this happen the day the user leaves? How long before > archiving > > > home directory and email? When are accounts finally deleted? > > > > > > Any pointers welcome. > > > > > > Thanks. > > > > > > -- nme > > > > > > -- > > > No virus found in this outgoing message. > > > Checked by AVG Free Edition. > > > Version: 7.1.375 / Virus Database: 267.14.24/244 - Release > Date: > > > 1/30/2006 > > > > > > PLEASE READ: The information contained in this email is > > > confidential and > > > > > > intended for the named recipient(s) only. If you are not an > > intended > > > > > > recipient of this email please notify the sender immediately > and > > > delete your > > > > > > copy from your system. You must not copy, distribute or take > > any > > > further > > > > > > action in reliance on it. Email is not a secure method of > > > communication and > > > > > > Nomura International plc ('NIplc') will not, to the extent > > > permitted by law, > > > > > > accept responsibility or liability for (a) the accuracy or > > > completeness of, > > > > > > or (b) the presence of any virus, worm or similar malicious > or > > > disabling > > > > > > code in, this message or any attachment(s) to it. If > > verification > > > of this > > > > > > email is sought then please request a hard copy. Unless > > otherwise > > > stated > > > > > > this email: (1) is not, and should not be treated or relied > > upon as, > > > > > > investment research; (2) contains views or opinions that are > > > solely those of > > > > > > the author and do not necessarily represent those of NIplc; > > (3) is > > > intended > > > > > > for informational purposes only and is not a recommendation, > > > solicitation or > > > > > > offer to buy or sell securities or related financial > > instruments. > > > NIplc > > > > > > does not provide investment services to private customers. > > > Authorised and > > > > > > regulated by the Financial Services Authority. Registered in > > England > > > > > > no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St > > > Martin's-le-Grand, > > > > > > London, EC1A 4NP . A member of the Nomura group of > companies. > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.375 / Virus Database: 267.14.25/246 - Release > Date: > > > 1/30/2006 > > > > > > > > > -- > > > No virus found in this outgoing message. > > > Checked by AVG Free Edition. > > > Version: 7.1.375 / Virus Database: 267.14.25/246 - Release > Date: > > > 1/30/2006 > > > > > > PLEASE READ: The information contained in this email is > > > confidential and > > > intended for the named recipient(s) only. If you are not an > > intended > > > recipient of this email please notify the sender immediately > and > > > delete your > > > copy from your system. You must not copy, distribute or take > any > > > further > > > action in reliance on it. Email is not a secure method of > > > communication and > > > Nomura International plc ('NIplc') will not, to the extent > > > permitted by law, > > > accept responsibility or liability for (a) the accuracy or > > > completeness of, > > > or (b) the presence of any virus, worm or similar malicious > or > > > disabling > > > code in, this message or any attachment(s) to it. If > > verification > > > of this > > > email is sought then please request a hard copy. Unless > > otherwise > > > stated > > > this email: (1) is not, and should not be treated or relied > > upon as, > > > investment research; (2) contains views or opinions that are > > > solely those of > > > the author and do not necessarily represent those of NIplc; > > (3) is > > > intended > > > for informational purposes only and is not a recommendation, > > > solicitation or > > > offer to buy or sell securities or related financial > > instruments. > > > NIplc > > > does not provide investment services to private customers. > > > Authorised and > > > regulated by the Financial Services Authority. Registered in > > England > > > no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St > > > Martin's-le-Grand, > > > London, EC1A 4NP. A member of the Nomura group of companies. > > > > > > > > > > -- > > Letting your vendors set your risk analysis these days? > > http://www.threatcode.com > > > > List info : http://www.activedir.org/List.aspx > > List FAQ : http://www.activedir.org/ListFAQ.aspx > > <http://www.activedir.org/ListFAQ.aspx> > > List archive: > > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > > > > -- > Letting your vendors set your risk analysis these days? > http://www.threatcode.com > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
