Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>One thing I am unclear on is your question about retrieving the domain name given a directoryentry in a domain controller. I am assuming that you have a server that can see multiple trusted domains, and that a user can log into your application from any one of them such that you don't know against what domain you need to test role membership.</p> <p>For controlling access to features via ADGroup membership, could you use the </p> <pre><code>HttpContext.Current.User.IsInRole("appdomain\groupname") </code></pre> <p>where User.Identity.Name=="userdomain\user". I'm not familiar with domain trust issues, but this assumes that you can add users from the trusted domain into the domain group that you control so you don't need to worry about the group domain location.</p> <p>If you can't, or if you have the same group name in each different domain, then you could do something like this? </p> <pre><code>HttpContext.Current.User.IsInRole(userDomainname + "\groupname") </code></pre> <p>Some points:</p> <ol> <li>unless you already have a large established AD codebase, I would recommend using objects from the System.DirectoryServices.AccountManagement namespace. </li> <li>I highly recommend the <a href="http://technet.microsoft.com/en-us/sysinternals/bb963907" rel="nofollow">ADExplorer</a> utility from Sysinternals to get a more LDAP view of your domain(s) which helps with LDAP connection strings and directory programming in general. </li> <li>If you are comfortable with interop, and need to perform any LDAP connection string parsing, check out this <a href="http://labs.episerver.com/en/Blogs/Johano/Dates/111974/112050/112051/" rel="nofollow">site</a>.</li> <li>The System.DirectoryServices.AccountManagement.<strong>PrincipalContext.Container</strong> and System.DirectoryServices.<strong>DirectoryEntry.Path</strong> properties return the LDAP connection string w/ the domain at the end of the string (i.e., DC=mycompany,DC=com)</li> <li>Don't forget about trusty old Environment.UserDomainName &amp; Environment.UserName (which grabs the WindowsPrincipal from the currently executing thread; see <strong>Table 1: Thread Exposed CurrentPrincipal Object</strong> @ <a href="http://msdn.microsoft.com/en-us/library/Aa480475.aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/Aa480475.aspx</a> for a great table on what the current user is within the asp.net runtime. )</li> </ol> <p>** UPDATE 6/8/2011 2:15 PM**</p> <p>If I understand AD correctly, the user's domain is an integral part of the user object returned by AD. Expanding on your example of "Bob Newaccountant"...</p> <p>So given the following 2 Domains with a trust between them:</p> <pre><code>1. "abcdc.com" CN=Users CN="Bob NewAccountant" 2. "abc.com" CN=Users CN="Local User1" OU=Applications OU=MyApplication CN=ReportReaders (Members: abcdc\BNewAccountant, abc\luser1) </code></pre> <p>You should get the users' info given the following query:</p> <pre><code>//name parameter = domain //container parameter = distinguished name using(var ctx = new PrincipalContext( ContextType.Domain, name: "abc.com", container: "OU=MyApplication,OU=Applications,DC=abc,DC=com", "abc\serviceaccountname", "Password1")) { var officeGroup = GroupPrincipal.FindByIdentity(ctx, IdentityType.SamAccountName, "ReportReaders"); foreach(Principal prin in officeGroup.GetMembers(recursive: true)) { Console.WriteLine("DistinguishedName: " + prin.DistinguishedName + " UPN: " + prin.UserPrincipalName); } //Should result in // DistinguishedName: CN=luser1,CN=Users,DC=abc,DC=com UPN: luser1@abc.com // DistinguishedName: CN=BNewAccountant,CN=Users,DC=abcdc,DC=com UPN: BNewAccountant@abcdc.com } </code></pre> <p>So you should be able to get the user's domain via <strong>distinguishedName</strong> or <strong>userPrincipalName</strong> properties of active directory. (Note: I don't have a dual domain setup handy to me so I am not able to test the above code at this time.) Is that getting closer?</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload