About Certificates

Please open internet explorer,
Tools > Internet Options >Content >Certificates > click certificates
It is very good.

Programming Directory Services

Programming Directory Services
Once you've got a WindowsIdentity for a user, you can use the classes in the System.DirectoryServices namespace to quickly do a lookup on his user account in Active Directory and discover all sorts of information about him:

•What's his phone number or e-mail address?
•What office is he in?
•Who is his manager?
•Who are his direct reports?
•What's his employee ID number?
You might expect the code for doing this to be really complicated, but it's surprisingly easy:

Copy
public string LookupEmail(WindowsIdentity id) {
using (DirectoryEntry user = LookupUser(id)) {
return (string)user.Properties["mail"].Value;
}
}
DirectoryEntry LookupUser(WindowsIdentity id) {
string path = string.Format("LDAP://", id.User);
return new DirectoryEntry(path, null, null, SECURE_BINDING);
}
AuthenticationTypes SECURE_BINDING =
AuthenticationTypes.Secure | // use platform authentication
AuthenticationTypes.Signing | // use integrity protection
AuthenticationTypes.Sealing; // use encryption

The trick is to use a technique called SID binding, where you get the user's security identifier (SID) from the WindowsIdentity.User property, which was introduced in version 2.0 of the .NET Framework. Then you hand that value off to Active Directory and boom, you've got a DirectoryEntry object that represents the user's account. This example looks up the user's e-mail address, but it would be just as easy to get the other properties listed above.

As you learn more about programming directory services, you should also spend some time familiarizing yourself with the schema that Active Directory provides by default. There is a ton of great information here that you can harvest for use in your applications, and the system administrator will be very happy that you're relying on a single source of truth for user data instead of creating yet another identity silo to store these sorts of details! The schema is documented in MSDN.

What about independent software vendors building applications that will be deployed at many different companies? Not all of those companies have Active Directory, you may be thinking. Here's the thing: most companies actually do run Active Directory, and of those that don't, most larger companies store user accounts in a directory service accessible via LDAP. It's a very good idea to build solutions that leverage those identity stores instead of building your own identity silo. If you end up in a situation where there is simply no directory service at all, you should consider deploying ADAM to store user accounts, which allows you to use System.DirectoryServices with the same schema you'd expect in Active Directory. The binding technique you'll use will be different in this case, but the overall programming model is the same.

ADAM is an interesting topic in itself. This is a full-fledged LDAP directory service based on the Active Directory code base, but without all the Network Operating System (NOS) infrastructure that you probably don't care about if you simply need an LDAP enterprise or application directory. It has the same replication features as Active Directory and can run on any machine (not just a domain controller). I'm running it as I write this paper on my Windows XP laptop, which makes it easy for me to program with System.DirectoryServices without having a domain controller around! It's easy to install, as you can see from this paper.

For more information on programming System.DirectoryServices, see The .NET Developer's Guide to Directory Services Programming.

from http://msdn.microsoft.com/en-us/library/aa480245.aspx