A CN (common name) is no good for logging in, because a CN alone does not uniquely identify a user. I could have a
CN=Ryan Ries,OU=Dallas,DC=Domain,DC=com
and I could also have a
CN=Ryan Ries,OU=New York,DC=Domain,DC=com
A user's CN is also an RDN (relative distinguished name.) They have the same CN, but different DNs. You might notice that you run into problems if you have two people in your organization named Ryan Ries, and you'll have to make the SamAccountName for the second one something like rries2.
A DN (distinguished name) isn't good to log in with, because who wants to log in to a system with a username like CN=ryan,OU=Texas,DC=brazzers,DC=com ? While using a DN does uniquely and definitively identify a user, it's annoying to have to type out. It's the same kind of concept between relative paths and absolute paths on a file system. It also implies that you know exactly where in the directory structure the object is located without having to search for it. Which you often do not.
This is called Ambiguous Name Resolution (ANR) - searching the directory for a user when you do not have his or her distinguished name.
UPN (User principal name) is pretty good because they look like email addresses, they can be the same as the user's corporate email address, they're easy to remember, and they are preferred to log in with because the name will be searched for in the local domain first, before searching for it in the forest.
Microsoft says: The point of the UPN is to consolidate the email and logon namespaces
so that the user need only remember a single name. The UPN is the preferred logon name for Windows users. Users should be using their UPNs to log on to the domain. At logon time, a UPN is validated first by searching the local domain, then the global catalog. Failure to find the UPN in the local domain or the GC results in rejection of the UPN. The UPN can be assigned, but is not required, when the user account is created.
Keep in mind that "not required" bit at the end when designing your applications.
SamAccountName is also good because SamAccountName needs to be unique for everyone in the domain (but not the forest.) In addition, SamAccountNames are short. Most people log in with SamAccountNames, even though they do not uniquely identify you in an AD forest, which is why you have to specify a domain name to go along with your SamAccountName so that the system knows what domain you are trying to log in to.
Here's some great documentation on the issue for further reading:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms677605(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680857(v=vs.85).aspx
In your test, you have:
cn=rene,cn=Users,dc=test,dc=site
In your configuration you have:
OU=Users,DC=test,DC=site
So... is Users a OU or a cn? Seems like this is your problem.
Best Answer
There used to be an Identity Management for Unix piece of AD that would allow you to specify home directories, user shells and other Posix attributes and allow users to authenticate from Linux via AD. This is no longer the case. As of Server 2008 that piece has been deprecated. You can try using ADSI Edit to set values by hand but the free-form entry can make things a mess if you're not careful. I don't know if there is a way to keep track of Unix UID/GID in a reasonable way either so as you don't end up duplicating them. I ended up going with SASL Passthrough. You have to find a way to manage it but in the end you're only asking AD for a password and nothing else. All the Posix attributes come from OpenLDAP. Running the bulk of it on Linux offers many tools for automating the management of the directory.