I am trying to access the onpremises active directory from the web application running on Azure. We have selected Azure Connect as it best fits our requirement (authenticate user as well as fetch user information from Active Directory).
I have followed the steps provided in this link1 and link2, but still failing to achieve the goal.
Below is the method, I a trying to test if the onpremises Active Directory is reachable from Azure: DirectoryEntry.Exists("LDAP Path")
Below is the error I am encountering:
System.Runtime.InteropServices.COMException (0x8007054B): The
specified domain either does not exist or could not be contacted.
at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
at System.DirectoryServices.DirectoryEntry.Exists(String path) at
WebRole1.MyLogInPage.btnSubmit_Click(Object sender, EventArgs e)
I can see the connect endpoint software is running fine without any connectivity issue, on the server running Active Directory and the endpoint group is properly setup.
Related
I'm attempting to query a remote machine with the PowerShell cmdlet: Get-WmiObject and using credentials for a user in Azure AD that has the Azure AD joined device local administrator role and the IAM role assignment of Virtual Machine Administrator Login on the remote machine.
When I run the following command:
Get-WmiObject -Class Win32_Process -Namespace "root/cimv2" -ComputerName <remote_computer_local_ip> -Impersonation Impersonate -Credential AzureAD\<username>
I receive the following error message:
Get-WmiObject : A security package specific error occurred. (Exception from HRESULT: 0x80070721)
Is the ability to run remote WMI queries supported when using an Azure AD user?
Remote machine specs:
Windows Server 2019 Datacenter
10.0.17763 Build 17763
Other troubleshooting notes:
I'm able to sign to the remote machine with the same user and have followed the steps in the https://learn.microsoft.com/en-us/azure/active-directory/devices/howto-vm-sign-in-azure-ad-windows document
When running the same command on the remote machine locally it properly returns the Win32_Process data
If I use the local administrator credentials on the remote command it also works which suggests that remote WMI is working
Both computers are Azure AD joined and show AzureAdJoined : YES from the dsregcmd /status command
I've attempted to use the Computer Name, Local IP, and FQDN and they all yield the same result
After talking with Microsoft support about this issue, it seems that the error stems from the different authentication methods between a local user account and an Azure AD account.
It seems it is not supported as they are using different authentication protocols.
Azure AD user uses OAuth and the security error is due to Kerberos.
Here is the reference article for more details: Authentication protocols in Azure Active Directory B2C | Microsoft Docs
They have also mentioned that there is no current information on whether or not this will be supported in the future and have recommend checking Azure updates for future product updates.
It could happen for number of reasons. Please check if any of these in your case is the one.
When You try to setup a WMI session when:
a. There are more than one computer accounts with the same name in play and one of those stale computer accounts resides in the same domain as your user account
b. Or when servers operating reside in the same AD DS forest but in different domains.
When server is not able to find the user object due to password credentials that may be stored as cache from previous login.
Incorrect time on machines/server that doesn’t match.
If firewalls are enabled for server which may restrict the access.
possible work arounds
Try azuread\user#mydomain.com or user#mydomain.com or domainame\username format to login or Try taking out the domain and adding it back again.
The local PC and remote PC must be in the same Azure AD tenant.
Run AAD delta Sync to make sure everything is Synced and make sure of internet connectivity and network.
Try if you can turn off firewall.
References:
remote access - AAD- Server Fault
rdp -Azure AD Joined - Server Fault
«0x80070721 | exchange12rocks.org)
A security package specific error occurred | Microsoft Docs
I'd like to add an offsite Windows VM to Azure Arc for health monitoring. The VM is hosted by Vultr and runs Windows Server 2016 Standard Build 14393.
However, installing AzureConnectedMachineAgent.msi on the target VM fails with error code 1603. Installation log also contains this error:
Start-Service : Service 'Guest Configuration Extension service
WixQuietExec64: (ExtensionService)' cannot be started due to the following error: Cannot start
WixQuietExec64: service ExtensionService on computer '.'.
WixQuietExec64: At C:\Program Files\AzureConnectedMachineAgent\ExtensionService\GC\Modules\Exte
WixQuietExec64: nsionService\ServiceHelper.psm1:367 char:5
Any suggestions on how to fix this?
You may Check if the user with which you are logged into the VM have
sufficient permissions to start a system service
If you find the following in the
%ProgramData%\AzureConnectedMachineAgent\Log\himds.log or in installation logs :
time="2021-02-11T08:39:38-08:00" level=error msg="Cannot open event source: Azure Hybrid Instance Metadata Service."
You can verify the permissions by collecting the following registry
key from an impacted server.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\Application\CustomS
Mitigation can be to grant the permission to write to the
SECURITY_SERVICE_RID S-1-5-6 which would grant the required
permissions to the himds service account.
https://learn.microsoft.com/en-us/windows/win32/secauthz/well-known-sids.
If the registry key does NOT exist on the impacted VM, then this
resolution will NOT apply as there will be a separate root cause such
as AV interference.
If the root cause is not found here ,then a procmon trace needs to be
taken to analyze the root cause for the msi not being able to start a
service.
( In case a procmon trace has to be analyzed , please open an MS
Support ticket)
To get support for Windows Agent and extensions in Azure, the Windows
Agent on the Windows VM must be later than or equal to version
2.7.41491.911. However the cause for the failure of agent installation is different in this case.
You may also want to check %programdata%\ext_mgr_logs\gc_ext_telemetry.txt log which must have had an entry something like this :
<GCLOG>........ Not starting Extension Service since machine is an Azure VM</GCLOG>
Cause:
This can happen while attempting to install the agent on an Azure VM.This is an unsupported production scenario.One Should not be installing this agent on an Azure VM as it conflicts with the Azure Guest Agent and interferes with Azure VM management.
If one wishes to use an Azure VM simply for testing purposes then
they can follow the below document for guidance
https://learn.microsoft.com/en-us/azure/azure-arc/servers/plan-evaluate-on-azure-virtual-machine
I am building a Release Pipeline on Azure DevOps. Part of my release is to copy a bunch of files to the Azure VM. As far as I understand, the target machine needs to have PowerShell 5986 port open.
I have a VM with port 5986 open (I verified that by invoking remotely some commands on this VM with "PowerShell on Target Machines" task).
I added "Windows Machine File Copy" task and filled fields:
- Source
- Machines
- Admin Login
- Password
- Destination Folder
In "Machines" field, I put IP of the target machine.
As a result of running the release, I'm getting an error:
Failed to Create PSDrive with Destination:
'\\11.11.11.11\C$\TargetDirectory',
ErrorMessage: 'The network path was not found' The network path was
not found
I also tried to put IP address with a port, in this form: 11.11.11.11:5986
Then, I got this error:
Cannot convert value "\23.97.151.221:5986" to type "System.Uri".
Error: "Invalid URI: The hostname could not be parsed."
Documentation (https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/windows-machine-file-copy?view=azure-devops) says that IP address with a port is allowed.
What's the issue here?
I was getting the exact same error while doing these:
Initially in my release pipeline, I had an agent job and I created a Windows machine file copy task under the job and filled in all details correctly. I set the Machines field with the public IP address of my target server (a Windows azure VM) and I always got this error you reported.
I tried to use the Azure file copy task instead but I was faced with another problem (error message: Unable to get FQDN for all resources in ResourceGroup: {resourceGroupName}) which I couldn't get to fix after a lot of efforts.
This is the solution that worked for me:
Instead of running an agent job, I ran a Deployment Group Job. With deployment groups, I didn't need an IP address to connect to my VM. Setting up a deployment group for your Azure VM is very simple and well explained here
I created a Windows Machine File Copy task under the Deployment Group job I added. I filled same details for the task except that instead of the IP address of the Windows VM, I entered the computer name in the Machines field and the file copy task ran successfully!
I hope this helps
The problem is because you can't use that task to copy files across Windows Domain boundary! That is to say, if you build on host A and want to copy files to host B, then A and B must be in the same Windows Domain, otherwise you'll get the error like
##[error]Failed to Create PSDrive with Destination: '\\your-server-name-or-ip\some\path', ErrorMessage: 'The network path was not found'
That is to say, if you're using a hosted agent, then you're not able to copy files with that task to any host you have, no matter it has a public IP or not, or a FQDN, because they are not in the same Windows Domain!
You have two options to work around it:
Use Azure File Copy task if your target is an Azure VM or Azure Storage
Use private hosted agent and make sure your target host and your private agent are in the same Windows Domain
Last but not least, the document should really make it clear! It wasted me a lot of time on solving the problem!
go to the destination folder, right-click the folder select properties,share option is there, click that one and share everyone option is there
The solution is to go to the target server and SHARE the directory where the files would be copied. In Windows, just go to Properties of the directory, Sharing tab, and Share it to the user which is used in the VSTS task.
The answer is pretty simple, the DevOps Tasks are actually running PowerShell on you VM and trying to create a PSDrive.
Try using the task mentioned in the screenshot below:
After a successful build using a hosted VS2017 agent, I'm trying to deploy on-prem using an local hosted agent which was setup using a domain account which should have sufficient permissions as it is in the local admin group. As I was digging around on this issue elsewhere, one user re-installed their agent using NTATHORITY\SYSTEM and it worked.
I d'ont really need to create or stop\start the website, just deploy the recent build artifact.
What permissions should I check or should I use another task?
019-04-06T21:03:10.3898646Z ERROR ( message:Configuration error
2019-04-06T21:03:10.3899503Z
2019-04-06T21:03:10.3899791Z Filename: redirection.config
2019-04-06T21:03:10.3900026Z 2019-04-06T21:03:10.3900293Z Line
Number: 0 2019-04-06T21:03:10.3900530Z 2019-04-06T21:03:10.3900852Z
Description: Cannot read configuration file due to insufficient
permissions 2019-04-06T21:03:10.3901076Z 2019-04-06T21:03:10.3901333Z
. ) 2019-04-06T21:03:10.8135484Z ##[error]Process 'appcmd.exe' exited
with code '5'.
An agent is running under a user. The error means that your user doesn't have permissions to read/modify the redirection.config file that is necessary to manage IIS.
You have multiple options to solve this.
Change the user were the agent is running under. In example: NTATHORITY\SYSTEM
Give permissions to the user were your agent is running under to the folder C:\Windows\System32\inetsrv\config. If you want to create app pools or websites etc, modify permissions are of course needed.
When we install Azure agent as a service(In Windows, search for 'Services' and look for something like Azure Pipelines Agent..), by default it is logged on as 'Network Service'. Change it to 'Local System' and the pipeline should be able to run IIS related tasks/commands.
I have configured an IIS application pool (win server 2012 r2) to use an active directory managed service account without any issues, but I cannot publish this application from Visual Studio using Web Publish. I use my own credentials to publish to the website, and the folder structure gets created properly, but then I see this error:
Web deployment task failed. ((2014-10-07 12:45:44 PM) An error occurred when the request was processed on the remote computer.)
(2014-10-07 12:45:44 PM) An error occurred when the request was processed on the remote computer.
The account 'mydomain\iismsa$' does not appear to be valid. The account was obtained from this location: 'system.applicationHost/applicationPools/MyWebApp'.
Some or all identity references could not be translated.
at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess)
at System.Security.Principal.NTAccount.Translate(Type targetType)
at Microsoft.Web.Deployment.Impersonator.GetNTAccount(String userName, String source)
I have already granted full permissions to the service account on the target folder on the server.
Has anyone successfully used a managed service account to run IIS app pool AND been able to publish remotely?