We have a WPF application that runs in full trust.
Part of the application checks the membership of a Windows AD group.
This works fine on a Windows 7 machine, but not on a Windows XP machine.
The error occurs on the following line:
PrincipalContext ctx = new PrincipalContext(ContextType.Domain, "domain name");
According to the article Managing Directory Security Principals in the .NET Framework 3.5, the "domain name" variable might not be needed. That is, if you are accessing an Active Directory in the same domain as your application, the domain name is not needed.
You use the name parameter on the PrincipalContext constructor in
order to provide the name of the specific directory to connect to.
This can be the name of a specific server, machine, or domain. It's
important to note that if this parameter is null, AccountManagement
will attempt to determine a default machine or domain for the
connection based on your current security context.
The solution or workaround to the problem (at least what worked for me on both XP and W7) is the following change:
PrincipalContext ctx = new PrincipalContext(ContextType.Domain, null);
Related
Samba3 uses SID's in the range S-1-22-1 for users and S-1-22-2 for groups. For instance, S-1-22-1-1-10042 is the UNIX user with uid 10042.
I would like to be either able to map such a SID into a name, like 'myunixaccount', similar to this functionality for Windows account mapping:
SecurityIdentifier sid = ...; // For instance from FileSystemAccessRule.
name = sid.Translate(typeof(NTAccount)).Value;
Windows itself is able to make this mapping, but I seem unable to find a mapping algorithm.
ADDED: Environment Description
Tested proposed solution on Convert SID to Username in C#. It did not help. Therefore some extra environment description:
Windows PC, either joined to a domain or standalone, running W7 Professional, x86.
File located on Samba-based drive. Samba authenticates to AD controller of domain.
Samba version: 4.0.3, running on Linux 2.6.18-238, x64.
PAM for Samba, interactive sessions etc.
AD controller is W2012 with some default UNIX extension attribute in the directory to allow mapping UID etc.
.NET Framework libraries 4.5.2.
ldap.conf:
piece of ldap.conf
nss_base_passwd=OU=nl,OU=xxx,dc=yyy,dc=local?sub(objectCategory=user)
nss_map_objectclass posixAccount User
nss_map_objectclass shadowAccount User
nss_map_attribute uid sAMAccountName
nss_map_attribute uidNumber uidNumber
nss_map_attribute gidNumber gidNumber
nss_map_attribute cn sAMAccountName
nss_map_attribute uniqueMember member
nss_map_attribute userPassword msSFUPassword
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute loginShell loginShell
nss_map_attribute gecos cn
nss_map_objectclass posixGroup Group
nss_map_attribute shadowLastChange pwdLastSet
Interactive logons on UNIX with Windows authentication work fine, dito for Samba shares. When using a PC on the domain, it doesn't ask for credentials.
Some samples, the user gle3 (highlighted in 1) also exists in the domain but with a different SID. The SID used here is the Samba SID, like S-1-22-1-1-10001.
In (2) you can see that the user exists in the used passwd configuration. The following of course yields no results: grep gle3 /etc/passwd, since the entries are used from remote server. The remote server maps the user SID of gle3 to UNIX uid 10001 and default group 10003.
In (3) you can see that the default group does not exist, and that is why the permissions can not resolve it to a name.
So obviously Windows somehow asks the file server: "give me the data on these SIDs" and the Samba file server respons somehow: Ok, that is "Unix User\gle3" and "Unix Group\10003" but I do not have a group name for that last one.
I've been toying around with this some time ago for building a local LAN crawler on a 2000+ computer network. I'm pretty sure that what you're asking is not part of the SMB protocol. You can actually see that: if Windows cannot resolve the credentials, it will show the SID's in the security properties.
Basically what happens is that a SID is an object ID (like a username / group) that's mapped to a unique ID. They work like GUID's. Usually PC's communicate in SID's, not in usernames.
Now, there's different kinds of SID you need to consider:
You have the Active Directory SID that you can resolve using the standard methods. Note that these include group and user SID's.
There's the local PC SID's that you can resolve using the standard methods. Again, group and user SID's. This probably works for Samba as well as Windows, although I've only tested it on Windows in the past.
There's SID's on remote PC's that normally cannot be resolved. Basically this is what happens if you get a NTLM token in any different way.
There's actually a lot more than this... certificate credentials, reserved users, etc are all also object ID's which can be used for logging in - but I'll just keep it simple. The key takeaway from this comment is that while all usernames have a SID, it's not true that all SID's also have a username.
If you have an AD somewhere (you seem to do), a proper setup contains all users here. The easiest way to get the complete mapping is to simply enumerate the complete active directory. That should contain all the mappings. Basically that works like this:
DirectoryEntry root = new DirectoryEntry("LDAP://dc=MyCompany,dc=com");
DirectorySearcher search = new DirectorySearcher(root);
search.Filter = "(objectCategory=Person)";
search.SearchScope = SearchScope.Subtree;
search.PropertiesToLoad.Add("objectSid");
search.PropertiesToLoad.Add("displayName");
foreach(SearchResult result in search.FindAll())
{
// grab the data - if present
if(result.Properties["objectSid"] != null && result.Properties["objectSid"].Count > 1)
{
var sid = result.Properties["objectSid"][0];
}
if(result.Properties["displayName"] != null && result.Properties["displayName"].Count > 0)
{
var userName = result.Properties["displayName"][0].ToString();
}
}
I'm trying to determine the last domain connection made by a user from a remote machine, regardless of if the machine is currently connected to the domain or not.
The closest I can get is using the System.DirectoryServices.ActiveDirectory and System.DirectoryServices.AccountManagement namespaces that do something similar to this:
Domain d = Domain.GetComputerDomain();
PrincipalContext c = new PrincipalContext(ContextType.Domain, d.Name);
UserPrincipal uc = UserPrincipal.FindByIdentity(c, "johndoe");
And then using the LastLogon property of the UserPrincipal.
This works fine, as long as the machine my application is running on is connected to the domain. If it isn't, Domain.GetComputerDomain() returns null, and I'm out of luck (even if I hardcode the domain name to the PrincipalContext constructor, it throws an exception when not connected to the domain). Is there some other AD property or registry key that gets stored locally on the remote machine when it makes an AD connection to the server that I could use?
The following link describing the LSA Cache seems promising, but, to my knowledge, there is nothing regarding domain connection timestamps that gets cached.
Determine User Active Directory Groups from Local Machine off Network
I am working on a project where I have to validate the Platform for Intel Atom processor and Windows 7 OS.
I have Used:
ManagementClass mgmt = new ManagementClass("Win32_Processor");
//for Intel Atom, "Win32_OperatingSystem" for Win 7 OS
Now, This Logic is working fine when login as Admin or Standard user, But When login as Guest User I am getting System.UnauthorizedAccessException in method:
void ThrowExceptionForHRInternal(Int32, IntPtr)
description: Access is denied
Is there any restriction for the Guest Account to fetch Platform details?
Yes they are.
You will not get around this without dcom changes or impersonation. I am not able to test it right now but I am quite sure the Environment class will throw a exception also.
You simply have restricted access as guest and that included most wmi access and most environment access that goes further than username. And impersonation is a bad thing in this context that I wouldn't do. I am not even sure that it will work for you in that case or just throws another Exception.
I am trying to create a new Active Directory user in .net 3.5 and I am recieving the following error "You were not connected because a duplicate name exists on the network."
I have googled the error and I can not find anything related to this on Windows server 2008 and .net 3.5.
I can create a new user when using AD users and groups on the server.
We are using identity impersonate and the user has full access to AD.
I can create the user on my local development machine.
This is on a Windows 2008 server using .net 3.5
Here is the code we are using:
newPassword = GeneratePassword()
ctx = New PrincipalContext(ContextType.Domain, "Domain",containerDistinguishedName)
user = New UserPrincipal(ctx, userName, newPassword, enabled)
' Force the user to change the initial password on first logon
user.ExpirePasswordNow()
' Commit the new object to Active Directory
user.Save()
' Return success
Return newPassword
It sounds like the server may be the thing that is not connected to the domain. This is possibly due to the machine being cloned and reusing the SID or name of the machine. Are you able to manage active directory users from this machine using the active directory users and groups tool?
I'm attempting to determine whether a user is a member of a given group using System.DirectoryServices.AccountManagment.
I'm doing this inside a SharePoint WebPart in SharePoint 2007 on a 64-bit system.
Project targets .NET 3.5
Impersonation is enabled in the web.config.
The IIS Site in question is using an IIS App Pool with a domain user configured as the identity.
I am able to instantiate a PrincipalContext as such:
PrincipalContext pc = new PrincipalContext(ContextType.Domain)
Next, I try to grab a principal:
using (PrincipalContext pc = new PrincipalContext(ContextType.Domain))
{
GroupPrincipal group = GroupPrincipal.FindByIdentity(pc, "MYDOMAIN\somegroup");
// snip: exception thrown by line above.
}
Both the above and UserPrincipal.FindByIdentity with a user SAM throw a DirectoryServicesCOMException: "Logon failure: Unknown user name or bad password"
I've tried passing in a complete SAMAccountName to either FindByIdentity (in the form of MYDOMAIN\username) or just the username with no change in behavior. I've tried executing the code with other credentials using both the HostingEnvironment.Impersonate and SPSecurity.RunWithElevatedPrivileges approaches and also experience the same result.
I've also tried instantiating my context with the domain name in place:
Principal Context pc = new PrincipalContext(ContextType.Domain, "MYDOMAIN");
This throws a PrincipalServerDownException: "The server could not be contacted."
I'm working on a reasonably hardened server. I did not lock the system down so I am unsure exactly what has been done to it. If there are credentials I need to allocate to my pool identity's user or in the domain security policy in order for these to work, I can configure the domain accordingly. Are there any settings that would be preventing my code from running? Am I missing something in the code itself? Is this just not possible in a SharePoint web?
EDIT:
Given further testing, my code functions correctly when tested in a Console application targeting .NET 4.0. I targeted a different framework because I didn't have AccountManagement available to me in the console app when targeting .NET 3.5 for some reason.
using (PrincipalContext pc = new PrincipalContext(ContextType.Domain))
using (UserPrincipal adUser = UserPrincipal.FindByIdentity(pc, "MYDOMAIN\joe.user"))
using (GroupPrincipal adGroup = GroupPrincipal.FindByIdentity(pc, "MYDOMAIN\user group"))
{
if (adUser.IsMemberOf(adGroup))
{
Console.WriteLine("User is a member!");
}
else
{
Console.WriteLine("User is NOT a member.");
}
}
What varies in my SharePoint environment that might prohibit this function from executing?
I added the account used by the IIS Application Pool to the Administrators group and this issue was resolved.