Install-ADDSDomainController Credential Error 12 - powershell

Hello,
I am trying to automate the installation and promotion of domain controllers, which are being added to an existing root forest with no child domains. I'm using the following code to perform this action during a ConfigMgr Task Sequence (so the script itself is being run as System):
function Install-DomainController
{
param(
[string]$CUST_DSRMPassword,
[System.Management.Automation.PSCredential]$CUST_ADDSCredentials
)
Write-LogEntry -Type Information -Message "Promoting the Server to a Domain Controller..."
try
{
Install-ADDSDomainController `
-NoGlobalCatalog:$false `
-CreateDNSDelegation:$false `
-CriticalReplicationOnly:$false `
-Credential $CUST_ADDSCredentials `
-Adprepcredential $CUST_ADDSCredentials `
-DatabasePath "$NTDSPath" `
-DomainName "$DomainName" `
-InstallDNS:$true `
-LogPath "$NTDSPath" `
-ReplicationSourceDC "$CUST_DomainControllerToUse" `
-SysvolPath "$SysvolPath" `
-Force:$true `
-NoRebootOnCompletion:$true `
-SafeModeAdministratorPassword (ConvertTo-SecureString -AsPlainText $CUST_DSRMPassword -Force)
}
catch
{
$ErrorMessage = $_.Exception.Message
$FailedItem = $_.Exception.ItemName
Write-LogEntry -Type Error -Message "The Item '$FailedItem' caused the following error: '$ErrorMessage'!"
}
}
The credentials are being passed as a parameter formatted as [System.Management.Automation.PSCredential]. I can verify the credentials are correct by opening a cmd window, running powershell and using the following code during runtime:
$CUST_ADDSCredentials.Password
$CUST_ADDSCredentials.GetNetworkCredential()
$CUST_ADDSCredentials.GetNetworkCredential().Password
And I know the user I'm passing on to the cmdlet is infact a member of the domain admins, enterprise admins and schema admins. Yet I still recieve the following error message:
User is not DA or EA. VerifyUserCredentialPermissions error message:
You have not supplied user credentials that belong to the Domain
Admins group or the Enterprise Admins group. The installation may fail
with an access denied error. Do you want to continue?
I'm puzzled as to what I'm doing wrong here. Would I perhaps be required to run the cmdlet in a different context by opening a seperate PSSession and using Invoke-Command -Session -ScriptBlock{}? Or is there perhaps something obvious I'm missing?
Thankful for any help :-)
Best Regards,
Fred

Related

Exchange hybrid enviornment powershell add user with a mailbox

What is the best way to add a user in a hybrid on-prem/o365 deployment with a mailbox? If I go into Exchange Admin Center on either the on-prem or o365 and add a recipient it replicates it out to the other EAC as well as adding the user to active directory on prem. Looking thru the powershell documentation it looks like the New-Mailbox command should do that but I cant get it to work. Here is what I have so far.
Connect-ExchangeOnline -Credential $credential -ShowProgress $true
Connect-AzureAD -Credential $credential
Connect-MsolService -Credential $credential
New-Mailbox -MicrosoftOnlineServicesID $uName"#mydomain.com" -Name "$fName $lName" -Password $secureString -ResetPasswordOnNextLogon $true
This creates the mailbox/user in o365 portal but not in on/off-prem EAC or active directory.
Steps:
First Create user and Assign a License
"New-ADUser -Name "user" -Accountpassword (Read-Host -AsSecureString "AccountPassword") -Enabled $true"
Enable remote Mailbox
"Enable-RemoteMailbox user -RemoteRoutingAddress user#domain.mail.onmicrosoft.com"

Azure Automation Runbooks, Connect-AzAccount, Assigning rights

I am trying to do some basic group management using Azure Automation, but I'm having a heck of a time getting the script to authenticate correctly.
I have added the Azure.Account modules to the runbook, and the connection seems to get established (at least, it doesn't throw an exception, and the returned object is not null).
When using "Get-AzAdGroup", I am getting:
Get-AzADGroup : Insufficient privileges to complete the operation.
The app account created is a "Contributor" in AAD, so as far as I understand, has full rights to the directory.
I have tried the solution listed at How to connect-azaccount in Azure DevOps release pipeline, to the same effect (Insufficient privileges). I have also applied "Group.Read.All", "Group.ReadWrite.All", "GroupMember.Read.All", "GroupMember.ReadWrite.All" based on what I can read from https://learn.microsoft.com/en-us/graph/permissions-reference#group-permissions - but I'm not 100% clear if the Az* cmdlets use the Microsoft Graph, or if that's separate altogether.
Code is as follows:
$connectionName = "AzureRunAsConnection"
try
{
# Get the connection "AzureRunAsConnection "
$servicePrincipalConnection=Get-AutomationConnection -Name $connectionName
"Logging in to Azure..."
<#
# Original, technically legacy.
Add-AzureRmAccount `
-ServicePrincipal `
-TenantId $servicePrincipalConnection.TenantId `
-ApplicationId $servicePrincipalConnection.ApplicationId `
-CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint
#>
$connectState = Connect-AzAccount `
-ServicePrincipal `
-TenantId $servicePrincipalConnection.TenantId `
-ApplicationId $servicePrincipalConnection.ApplicationId `
-CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint
<#
# From https://stackoverflow.com/questions/56350960/how-to-connect-azaccount-in-azure-devops-release-pipeline, same result.
$AzurePassword = ConvertTo-SecureString "*****" -AsPlainText -force
$psCred = New-Object System.Management.Automation.PSCredential($servicePrincipalConnection.ApplicationId , $AzurePassword)
$connectState = Connect-AzAccount -Credential $psCred -TenantId $servicePrincipalConnection.TenantId -ServicePrincipal
#>
if ($connectState) {
"Connected."
} else {
"Doesn't seem to be connected."
}
}
catch {
if (!$servicePrincipalConnection)
{
$ErrorMessage = "Connection $connectionName not found."
throw $ErrorMessage
} else{
Write-Error -Message $_.Exception
throw $_.Exception
}
}
# Get groups
Get-AzADGroup
My gut tells me that since both connect-azaccount methods yield the same result (connected, but no access) my issue isn't necessarily in the script, but short of creating a service account (which presents challenges with MFA), I don't know how to fix this.
From the solution How to connect-azaccount in Azure DevOps release pipeline I provided, in the screenshot, it is clear that you need to add the API permission of Azure Active Directory Graph, not Microsoft Graph.
Please add the Directory.Read.All in Azure Active Directory Graph for the AD App of your automation run as account.
I have faced a very similar issue. You have a problem with the API permissions Azure APP has.
In my case, my azure App was working as a Service Principal, and not only modifying some stuff in the Azure AD, but also some Azure resources, therefore, these were the api permissions that I had to grant:
Remember that you also need to grant admin consent from the Azure tenant for these permissions update.
If you just assign Contributor role to the service principal, you just can use the sp to get Azure resource(such as VM, app service). So if you want to use the sp tp get Azure AD resource, we need to assign Azure AD role (sucah as Directory Readers) to the sp. For more details, please refer to the document and the document
The detailed steps are as below
Get the RunAsAccount sp object id
Confugure Permisisons for the application
connect-AzureAD
$sp=Get-AzureADServicePrincipal -ObjectId <the sp object id your copy>
$role=Get-AzureADDirectoryRole | Where-Object{$_.DisplayName -eq "Directory Readers"}
Add-AzureADDirectoryRoleMember -ObjectId $role.ObjectId -RefObjectId $sp.ObjectId
Test
a. create a new runbook
$servicePrincipalConnection=Get-AutomationConnection -Name 'AzureRunAsConnection'
$connectState = Connect-AzAccount `
-ServicePrincipal `
-TenantId $servicePrincipalConnection.TenantId `
-ApplicationId $servicePrincipalConnection.ApplicationId `
-CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint
if ($connectState) {
"Connected."
} else {
"Doesn't seem to be connected."
}
Get-AzADGroup
Go to Azure portal --> Azure AD --> roles and Administrator-->Directory Readers role --> assign this role to the runbook account name

Start-Job with credential in custom task problems

I am trying to develop a custom task using Powershell which needs to use Start-Job -Cred to switch to another user in places. Agent is running as user A and I need to switch to user B. Logging in to the server running the agent as user A and then running the script works fine - the Start-Job switches credentials and runs a scriptblock as user B.
Running exactly the same thing from VSTS in the cloud using the same (on-prem) agent server running the agent as user A fails with the uninformative error:
"The background process reported an error with the following message: ."
I have done more debugging and there is no other error message anywhere. It seems to be related to the -Cred parameter of Start-Job as it makes no difference what is in the script block run and if I remove the -Cred parameter, it's also fine.
User A is in the Adminstrators group on the server running the agent
Agent runs as user A
Any ideas?
Try it with Invoke-Command, for example (output current user name):
$mypwd = ConvertTo-SecureString -String "[password, could use variable]" -Force -AsPlainText
$Cred = New-Object System.Management.Automation.PSCredential('[user name]',$mypwd)
$scriptToExecute =
{
$VerbosePreference='Continue'
Write-Output "$env:UserName"
# Write-Verbose "Verbose" 4>&1
}
$b = Invoke-Command -ComputerName localhost -ScriptBlock $scriptToExecute -Credential $Cred
Write-Output "Content of variable B"
Write-Host $b
Based on your experiences, your credentials are not being passed properly. Try this method and insert it into your script:
Outside of your script, get the securestring object-
Read-Host -AsSecureString | ConvertFrom-SecureString
Take the output of this command (where you enter the password), and put it before your start-job-
$Secure = ConvertTo-SecureString -String 'above output'
$Cred = New-Object System.Management.Automation.PSCredential('Username',$Secure)
Start-Job -Credential $Cred
The SecureString can be reversed by someone with know-how, but if the script and/or account is secure, then that doesn't matter.

adding a domain controller by powershell script

Here is my code
# Create New Domain Controller
Import-Module ADDSDeployment
Install-ADDSDomainController -InstallDns -Credential (Get-Credential BPLTest.lab\Administrator) -DomainName "BPLtest.lab"
-NoGlobalCatalog:$false
-InstallDns:$True
-CreateDnsDelegation:$false
-CriticalReplicationOnly:$false
-DatabasePath "C:\NTDS"
-LogPath "C:\NTDS"
-SysvolPath "C:\SYSVOL"
-NoRebootOnCompletion:$false
-SiteName "Default-First-Site-Name"
-Force:$true
Now this code should install a domain controller into the my BPLTest.lab domain in my lab. I have run the ad prerequistes and also added RSAT tools for AD in another prior script. They work perfectly. However this script will install domain controller but I cant get it adjust things like the SysvolPath, DatabasePath and logpath. It keeps telling me it doesnt recognise these cmdlets.
ANy ideas what I am doing wrong
PowerShell will assume the Install-ADDSDomainController line is complete and won't look on the next lines for more parameters.
You need to tell it there is more to the command by ending a line with a backtick:
#Create New Domain Controller
Import-Module ADDSDeployment
Install-ADDSDomainController -InstallDns -Credential (Get-Credential BPLTest.lab\Administrator) -DomainName "BPLtest.lab" `
-NoGlobalCatalog:$false `
-InstallDns:$True `
-CreateDnsDelegation:$false `
-CriticalReplicationOnly:$false `
-DatabasePath "C:\NTDS" `
-LogPath "C:\NTDS" `
-SysvolPath "C:\SYSVOL" `
-NoRebootOnCompletion:$false `
-SiteName "Default-First-Site-Name" `
-Force:$true
Or by putting the variables into a dictionary of parameters first, and then 'splatting' them into the cmdlet as described here: https://stackoverflow.com/a/24313253/478656

How to login from an Azure Resource Manager Runbook?

Using the new Azure portal, I am trying to add a powershell runbook that will start a specific VM. This is not something that will be run in powershell from my PC, it will instead run as an ARM job. I can't seem to find a way to successfully login.
If running from my desktop in powershell I can just call Login-AzureRmAccount and it will launch a login dialog before running any further steps. From what I've read on the web it seemed that what I needed to do was add a credential to my automation account, retrieve it and then call the same Login method. I've now done that, but still can't log in.
Import-Module AzureRM.Compute
$AutomationCredentialAssetName = "automation"
$Cred = Get-AutomationPSCredential -Name $AutomationCredentialAssetName
Write-Output $Cred
Login-AzureRmAccount -Credential $Cred
Start-AzureRmVm -Name 'myvmname' -ResourceGroupName 'myresourcegroupname'
The credential is being retrieved correctly (get's written to output) but the call to the Login-AzureRmAccount fails with:
Login-AzureRmAccount : unknown_user_type: Unknown User Type
At line:10 char:1
+ Login-AzureRmAccount -Credential $Cred
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Add-AzureRmAccount], AadAuthenticationFailedException
+ FullyQualifiedErrorId : Microsoft.Azure.Common.Authentication.AadAuthenticationFailedException,Microsoft.Azure.Com
mands.Profile.AddAzureRMAccountCommand
If I don't attempt to log in first I get a message telling me to call Login-AzureRmAccount first.
How do I authenticate from within a runbook so that I can run automation tasks? What am I doing wrong?
We have subsequently discovered the the automation account created a connection when created that can be used to login:
$connectionName = "AzureRunAsConnection"
try
{
# Get the connection "AzureRunAsConnection "
$servicePrincipalConnection = Get-AutomationConnection -Name $connectionName
"Logging in to Azure..."
Add-AzureRmAccount `
-ServicePrincipal `
-TenantId $servicePrincipalConnection.TenantId `
-ApplicationId $servicePrincipalConnection.ApplicationId `
-CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint
}
catch {
if (!$servicePrincipalConnection)
{
$ErrorMessage = "Connection $connectionName not found."
throw $ErrorMessage
} else{
Write-Error -Message $_.Exception
throw $_.Exception
}
}
At a guess you are trying to log in with a Microsoft account, which can only be done interactively (as it needs to redirect through live.com). You will need to create a user within the tenant (Active Directory) that you are authenticating against in order for non-interactive login to work.
The easiest method to make this work is to create an account in the old portal (the new portal doesn't support Active Directory management yet) and then to add that user as a co-administrator in settings > administrators.
You can create a user through Powershell, and assign much more granular permissions, but while you're working your way around things it is probably easier to stay within the portal.
There is no significant difference between a user created through the old portal and one created via AzureRm commands.
I just encountered the same problem and while the information posted here was helpful it didn't solve the problem completely.
The key insight I needed was that in order to use Azure Cmdlets one has to configure a 'Run as Account'. (See https://learn.microsoft.com/en-us/azure/automation/automation-sec-configure-azure-runas-account)
It can be set up under Account Settings section of the azure automation account.
Once you have the 'Run as Account' you can use the method proposed by BlackSpy to log in. Namely:
# Get the connection
$servicePrincipalConnection = Get-AutomationConnection -Name AzureRunAsConnection
"Logging in to Azure..."
Add-AzureRmAccount `
-ServicePrincipal `
-TenantId $servicePrincipalConnection.TenantId `
-ApplicationId $servicePrincipalConnection.ApplicationId `
-CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint
Hope this might help someone.
The official advice is to use a ServicePrincipal for automation - you can either use Secret or Certificate credentials with a service principal, and certificates work the best.
It is still possible to use a work or school account for automated login (Login with just -Credential), but this requires that your organization does not require two-factor authentication. It is unfortunately not possible to use a Microsoft Account for this - microsoft accounts require user interaction for any login.