I think, to become a proof you have to publish so many papers and be invited into the position by a university. Well, that's what a friend of mine who's a Doc in geology said anyway :)
For Troup Bywaters + Anders Tim Sutton T: +44 (0) 113 243 2241 F: +44 (0) 113 242 4024 E: [EMAIL PROTECTED] W: www.TBandA.com Eastgate House 10 Eastgate Leeds LS2 7JL Office Location Map -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Williams Sent: 02 February 2006 17:15 To: [email protected] Subject: Re: [ActiveDir] User Account Lifecyle -- Best Practices Yeah, here in the UK a PhD or however you write it means you have done your B.Sc (degree) (or equivalent), your M.Sc (masters degree) and then you do your PhD - which makes you a doc. Not sure how you then become a professor. Something to do with rank in the university I think... PhD doesn't mean a specific discipline - you can do it in any subject that your university "does", and you usually specialise in an area of that subject. ----- Original Message ----- From: Brian Desmond <mailto:[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, February 02, 2006 3:57 PM Subject: RE: [ActiveDir] User Account Lifecyle -- Best Practices Well here, phd means anyone that's done post masters degree work - usually it goes BS MS PhD. I know a Doctor of Library Science ... just have to find a university that's accredited to make you a doctor of whatever. Thanks, Brian Desmond [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> c - 312.731.3132 ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, February 02, 2006 10:01 AM To: [email protected] Subject: RE: [ActiveDir] User Account Lifecyle -- Best Practices Dr J (PhD - means what exactly?) - Doctor of Psychology. In short, the guy took a 3 year degree and then took a 3 year post grad PhD course (doesn't matter what the subject matter was). He is therefore known as *Dr* Jesper J. What is the equiv over your side of the pond? neil ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: 02 February 2006 14:02 To: [email protected] Subject: Re: [ActiveDir] User Account Lifecyle -- Best Practices This is fun :) Dr J (PhD - means what exactly?) I think you're referring to this section of the paper in the first link Why You Should Not Use Account Lockout Even though the guide recommends configuring account lockout at 50 tries, I urge you not to configure account lockout. First, as the initial article of this series described, the chances that an attacker will guess a reasonable password are so remote as to not justify this option. Second, an attacker is highly likely to take your account lockout setting and convert it to a denial-of-service attack by locking out every account on the system. Third, most vulnerability assessment tools will lock out all the accounts on your domain. In the end, whether you use account lockout is a matter of your security policy, and debate whether it provides value. Keep in mind, however, that account lockout problems represent some of the most frequent technical support issues with Microsoft support services, and resetting an account costs an average of $70 per incident. If your security policy is so stringent that you believe these numbers are acceptable, and your policy cannot enforce reasonable passwords, you might still choose to configure account lockout. If not, do your Help Desk and budget a favor, and avoid it. I see the point. I disagree with the assertion that seems to have been throttled back for public consumption. I also would say that if your vulnerability assessment tool locks out your accounts after 50 tries, you're using the wrong vulnerability tool. Microsoft should consider using automated reset tools if it costs them that much <G> No, in the end I'm a believer that if your user can't get the password right after x number of tries (in this case, 50 is the recommended) then they SHOULD call the helpdesk because <insert deity> knows that they need it at this point. No question in my mind. And that type of support incident is exactly what a help desk is for: silly user tricks. Does that apply to SBS? In my opinion it should. If you can't remember your password after 10 tries, odds are you aren't going to. Write it down and paste it under your keyboard if it's such a problem.[1] I don't think I recognize Steve in that last link. His hair looks blonde in that photo. ?? In the end Susan, I get what they're trying to say. I know they're trying to make a case for not using account lockout and are using the cost as a justifying factor. They're also pushing for the use of long pass phrases vs. passwords. I've even heard some comments to the effect of using passphrases that insanely long and not ever requiring the user to change it. Additionally, there was a report not long ago by some brain-trust reporting org that predicts the usage of passwords will be insufficient by 2007 (can't find the link at the moment, but I'll have a look next opportunity if you like) because password crackers will be too good. Does this point to an idea that we should do away with passwords, account lockout, and password complexity? I've heard California is going to fall in the ocean due to some massive earthquake. I haven't decided to buy beach front property in Nevada yet nor do I think that doing away with account lockout is the answer to the problem. Neither are super-long passphrase requirements nor smart card logons, etc. These are all parts of a solution, but not the end because this is not a one-size fits all solution. FWIW, it is not the first time I've disagreed with Microsoft's assertion on security matters. Usually not because they're technically wrong, but because they don't have enough perspective to make it work in more than one scenario. I recall many long conversations regarding ISA and whether DMZ topology was valid anymore (or less). I think we still have different perspectives. That's how they work though: they'll continue to refine the ideas until it is the best idea out there. I respect and admire that very much. I also strive to get to that level of refinement. [1] let's face it, you may want to find another line of work anyway. I in no way endorse that idea, but rather just want to use it to illustrate a point. Hopefully nobody takes that seriously but if you do, do so at your own risk! "Security - Does one size fit all?" -ajm On 2/1/06, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] <[EMAIL PROTECTED]> wrote: 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]> <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:* [email protected] > <mailto: [email protected]> > > *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] > <mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>* < > > [EMAIL PROTECTED] > <mailto: [EMAIL PROTECTED] <mailto:[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] <mailto:[EMAIL PROTECTED]> >> > > *Sent:* Wednesday, February 01, 2006 3:37 AM > > *To:* [email protected] > <mailto: [email protected]> > > <mailto:[email protected] > <mailto: [email protected] <mailto:[email protected]> >> > > *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:* [email protected] > <mailto:[email protected]> > > <mailto: [email protected] > <mailto:[email protected]>> > > *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] > <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:* [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > *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-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-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-4 ae7-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-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-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-4 7DC-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:* [email protected] > <mailto:[email protected]> > > <mailto: [email protected] <mailto:[email protected]> > <mailto:[email protected]>> > > *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 <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/ 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. Groupshield 6.2 - Troup Bywaters & Anders Privilege and Confidentiality Notice This email and any attachments to it are intended only for the party to whom they are addressed. They may contain privileged and / or confidential information. If you have received this transmission in error please notify the sender immediately and delete any digital copies and destroy any paper copies. Thank you. 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/
