Does DirectoryServices.AccountManagement.PrincipalContext work on a remote Win 2012 R2 Sever? - account-management

This is my scenario and so far I have not found a way around it: The app runs on a Windows 2012 R2 server (svr1, a domain member), and needs to add a domain account to a local group on svr2, also a domain member.
Using ADSI hasn't worked for me so far (still trying). PSEXEC is not an option since clear text credential are sent over the network.
This is the line that works on remote Windows 2008 R2 servers, and does not on remote Windows 2012 R2 servers because the ConnectedServer property throws a 'System.UnauthorizedAccessException' but only when accessing a 2012 R2 server. Credentials are valid Domain Admin creds (works on 2008 R2 & I can log in to the dev server using them)
using ( PrincipalContext adDestMachinePrincContext = new PrincipalContext( AccountManagement.ContextType.Machine,"svr2",null,ada.ContextOptions.Negotiate,
"DomainName\\TheDomainAdminAccount","LegitPassword" ) )
{ ... etc etc etc ... }
What I've found so far is this:
Credentials are valid because the same line works on a remote 2008
R2 server.
Remote 2012 R2 is where my issue lies, and I have not
tested against 2016 yet.
When I login to the development server
using the same Domain Admin credentials, it works when the current
user's credentials are used. This line works, every time, when the
current user is the same Domain Admin
PrincipalContext x = new ada.PrincipalContext(AccountManagement.ContextType.Machine,"svr2" );
The goal (and at this point, I don't care how I get it done) is simple: Add a domain user account into a local group on a remote server, using .Net. PowerShell is not an option, though even a working snippet could . The remote box is anything from 2008, 2008 x86, 20058 R2, 2012, 2012 R2 or 2016.
It's not a credentials issue. Covered that above.
It's not a permissions issue. Covered that above also.
Running the executable "run as administrator" does not make a difference
Has anyone been able to add a domain account into a local group on a remote 2012 R2 server? I haven't found anything close anywhere with a working example yet. If so, what worked for you?
I'm not sure that ADSI calls will work because AD requires LDAP, local access requires WinNT and they don't seem to overlap with being able to do what's needed.
I think that's everything I have... so far.
My next step might be a WCF service that runs under a domain admin account, but that has to be overkill for this.

So far, Matt Johnson's post did the trick and this is working:
StackOverflow solution by Matt Johnson (he deserves his props!)
Add the Impersonation class
Change the code above to use the new class and this works, regardless of the Windows server OS:
The code snippet in my original post sort of looks like this now (simplified):
using ( new Impersonation( "TheDomain", "TheDomainAdminAccount", "ItsValidPassword" ) )
{
using ( PrincipalContext adDestMachinePrincContext = new PrincipalContext( AccountManagement.ContextType.Machine,"svr2") ) { ... etc etc etc ... } }
And it's working.

Related

How to configure Share Point 2010 on windows 7 with windows authentication

I have already install sql server 2008 r2 which is login by using windows authentication.
And then after install Sharepoint2010 foundation on my Windows7 Ultimate OS.
Now Next step is SharePoint Products Configuration Wizard. Click on next button i reach to Connect to server farm where is select Create new server farm and click to Next.
Then It Popup with below screen,
I have problem here is that it require Database access account with UserName and Password and UserName in form DOMAIN\User , but i dont have User Name with domain,then i create login user for sql server and it have name like SharePointUser with Password. There is no domain name.
I tried to enter user Name like Aamir-PC\SharePointUser, but gives error like User Name is invalid. The Account must have valid domain account. Even i tried username like SharePointUser but same error again.
I search a lot but i did not find any solution for above problem.
If you have SQL server installed on the same machine then Did you try to create a stand alone system instead of Server farm? I have installed Sharepoint 2010 foundation in my Windows 7 OS but as a standalone farm.

How do I authenticate to a SQL Server database on a domain from a virtual machine off the domain?

I am supporting a .NET 4.0 (Visual Studio 2010) web application that authenticates to a SQL Server 2008 database which resides on my work intranet. The application authenticates to the database using windows authentication. Thats all fine and dandy if Im developing on my host, but I am developing on a virtual machine that is not on the work domain. Thus when the project build and runs, it throws a SqlClient.SqlException
"Login failed. The login is from an untrusted domain and cannot be used with Windows authentication."
Short of developing on my host and abandoning the VM, what can I do to avoid this error and successfully authenticate to the database so I can build/run the web app? I am willing to store my credentials somewhere locally, though preferably not somewhere that would be under TFS source control (like the web.config) because I couldnt keep the file checked out since there are other developers on the project.
I have tried running Visual Studio as a different user (as the user on my work domain) but I get a "unknown user name or bad password" error.
Note, adding the Virtual Machine to the domain (or connecting to it via VPN) are not options. The VM must remain off the domain. Also note, the virtual machine is running on the computer that is on the domain, and the VM uses a shared connection. So it CAN access the intranet but it can't perform windows authentication to SQL Server.
You can run Visual Studio (or SQL Server Management Studio) as the user on the domain. The trick is, you have to use the “/netonly” option of the “runas” Windows tool, so that you can run as a domain user on a non-domain machine.
Namely, in a command prompt you run this command (filling in your own criteria):
runas /netonly /user:<Domain>\<User_Name> "<Your_Program.exe>"
Alternatively, you can create a shortcut on your desktop, and set this command as the shortcut target. Upon running the shortcut/command, you enter your credentials when prompted and visual studio (or whatever program you like) will run as the domain user.
Join the domain using vpn connection if possible. Vpn can connect you with specific domain credentials. Alternative would be connecting using SQL Server Authentication if SQL Server is configured with mixed authentication.
From what I understand, you have several options:
You could add a user account to the SQL db to allow password authentication
Have the VM join the domain
Create an SSH tunnel to the host SQL server port

Remote OpenSCManager fails with access denied

I am attempting to control a service on a remote machine using the following code:
// Error checking omitted for brevity
HANDLE hToken = NULL;
// user = username with no domain specification
// domain = targetmachine when targetting computer outside of domain
LogonUser(user, domain, password,
LOGON32_LOGON_NEW_CREDENTIALS, LOGON32_PROVIDER_WINNT50, &hToken);
ImpersonateLoggedOnUser(hToken);
SC_HANDLE hSc = OpenSCManager(targetmachine,
SERVICES_ACTIVE_DATABASE, SC_MANAGER_ALL_ACCESS);
This works fine when run from a computer within our local domain and targetting a machine on the same domain, both when using the credentials from the currently logged on user as well as when using other credentials.
However, when I attempt to target a machine that is not on any domain, the OpenSCManager call fails with access denied if I specify anything other than SC_MANAGER_CONNECT as the desired access. Targetting a domain computer from a computer that is outside the domain works (using user/domain/password combination for a domain user that is a local administrator on the target machine). Targetting a computer outside the domain from a computer outside the domain does not work.
The user/password is for a member of the administrator group on the target computer, so there should not be a problem with the account rights.
I've checked the scmanager security descriptor using sc -sdshow scmanager and it is identical for the domain computer and the non-domain computer. Both are running Windows 7 64-bit.
I've also tested to use psexec, which has the same symptoms, i.e. works fine between domain computers but not when targetting non-domain computer.
I have also tested to disable RPC over TCP on the target machine and rebooting it, as this is described as a possible cause for access denied errors but this does not appear to help. I've also tested to disable the Windows Firewall on the targetmachine, but no change.
Is there some setting that needs to be enabled in order for remote configuration of services to work?
It appears that this was caused by new security features from Windows Vista and above. By default, Windows will not grant remotely connecting users full administrator rights unless it is being done within a domain. So in order for this to work, User Account Control Remote Restrictions need to be turned off, but of course this will also lower the security of your computer.
Thanks to Hans Passant for recommending to check for similar issues posted on serverfault.com.

How to connect to SQL Server with Windows Authentication when not logged in with that username?

We created a local windows username on the database server and used it on a separate machine in IIS7's app pool in the same workgroup. The website app works to log in to the database server.
Now I am on my machine developing in VS 2010 trying to remotely access the database. The user and workgroup don't match on my machine to the web/database servers so I specify the username and password explicitly. When I try to connect VS 2010 to SQL Server 2008 I get the following error:
Cannot open user default database. Login failed.
Login failed for user 'myuser'. (Microsoft SQL Server, Error: 4064)
I have the correct username and password. I am not interested in matching their workgroup and username on my local machine.
How does one log in using Windows Authentication when your local username and workgroup are different from the database server's username and workgroup?
It worked to turn on SQL authentication, enable the sa account, and log in from my home machine. It wouldn't log in with 'myuser' remotely, but does work locally.
The "runas" command almost works:
runas /netonly /user:domain\username "devenv.exe"
You will be prompted for the password. You can also use "cmd.exe" as the final parameter to get a Command Prompt as that other user.
As I said, it almost works for me. I've been able to connect before, but not use SSMS successfully. I was dealing with a VPN as well, so if you have a less restricted path to the server perhaps it will work better for you.
Can you remote into your work machine and use it?
I do this all the time with SQL Server Management Studio for SQL Server 2008 and 2005 (and VS 2010). RUNAS works perfectly, but SSMS will still display your local username in the login screen. Just ignore that and you should be able to access the database without trouble. E.g.: if your local account is mylaptop\fma1 and you log into the mycompany domain as mycompany\jsmith, SSMS will still say "mylaptop\fma1" but will log into the database as mycompany\jsmith.
Microsoft has a Sysinternals addon called "Shell Run As" that lets you do this from Explorer:
http://technet.microsoft.com/en-us/sysinternals/cc300361
Just copy the downloaded file into an appropriate directory, run the .exe with /regnetonly as the argument, and you'll be able to shift-right-click and run as a different user.

How to remote debug when user accounts do not match?

How can I configure Visual Studio remote debugging when:
My developer machine is a member of an AD domain, and my username is "DevelopersName".
The "remote" machine is on the same Ethernet segment, but is not part of the domain.
The "remote" machine must run software under "RemoteUserName".
Most documentation I can find suggests that you need have both machines in the same domain and with identical usernames. That's not possible here.
I could possibly add my username to "remote", but the software still needs to run under "RemoteUserName.
If it helps, I could add 2nd network card to my developer machine and directly connect the "remote" machine.
Using VS2008, but will be moving soon to VS2010.
Thank you.
Sorry, but I've just spent the last 10 hours trying to debug your exact problem. My findings are not good.
You need to get your accounts synced, especially if you are using your remote app to connect to other systems in your SOA environment, ie: Sharepoint, AD.
You can to some extent get remote debugging to work, if you create an account on your local machine with the same name as that of your remote machine (lets do it like this rather rather than working with the domain account).
You then need to make sure the remote service is running under this account, and its a member of the administrators group. And by this I mean hold down control, and right click run as - with the remote debugger, and select the user (not required if remote server is logged in as the required user).
Run the wizard it will open the required ports, use Authentication, because non authentication won't debug managed code. Breakpoints are never met, and there is nothing you can do about this.
On your local dev machine, log off your domain account, and log onto the local account with matching name as the account on server thats running the remote service.
Now you stand a change of remote debugging. If you can't do any of the above, sorry there is no workaround, its entirely dependent on the user account and having the right permissions.
If you don't want to create a local account, try starting our debugger via command prompt using the following command:
runas /user:[user#machinename] /netonly [debugger.exe]
E.g.:
runas /user:john#mypc123 /netonly devenv.exe
I assume it's managed debugging you're talking about (for native debugging there's a remote debugging solution with no authentication). In this case, I would suggest that you use a local user to launch the debugger on your machine. If this local user's name and password match "RemoteUserName"'s name and password, it should work.
(Note that this does not preclude you from using the AD account to log in to your workstation, you just need to set up another account and use runas to launch Visual Studio.)

Resources