Greeting Everyone,
Hoping someone has a quick insight but I am getting access denied on a service account using the PowerShell command Remove-CMDevice.
This process is as per outlined here, https://technet.microsoft.com/en-us/library/jj821759(v=sc.20).aspx
The account has permission to remove devices from SCCM and this works fine through the GUI but not the command line. I have been unable to find documentation on what permissions the account need to do this via command line, it works fine manually in the GUI.
If anyone can shed light on this it will be wonderful, I do want to keep this service account as having as minimal permissions as possible.
Many thanks,
Edit to Add Image as follows,
After a lot of testing, I'm here with an answer on the Permission part when using PowerShell console to remove CM system object. Of course the symptom is the same: The account can delete from Admin console, however, when using PowerShell, it failed with Permission error message.
The account to perform the Remove-CMDevice cmdlet must have proper RBA Permission on the object. Assume the security scope is default one, the account connected to Configuration Manager console must have below RBA permission which I tested is almost minimal permission:
In the screenshot the Collection part, the permission is easy to understand, Read, Delete Resource, etc.
For the Computer Association part, you may get confused, why?
Steps I did the troubleshooting:
I opened a PowerShell Console connecting to Configuration Manager using my test account and run below command to see what will happen:
Remove-CMDevice 'Rsuraceccc' -Verbose
I got below error:
Yes, it's trying to querying from the SMS_StateMigration. Then I try to run a simple command:
Get-WMIObject -NameSpace root\sms\site_clt -Query 'Select * from SMS_StateMigration'
Once again, I got error. So I get the conclusion that the account needs Permission on SMS_StateMigration. So I add 'Recover User State' permission of Computer Association on the role and tried again, cheers, this time all command runs successfully.
I don't know why it's using SMS_StateMigration, but this is the case here.
Related
I'm running a Powershell logon script which sets users' Outlook signatures.
For debugging purposes, I'd like to log information in the client's Windows event log.
Using the New-Eventlog -LogName "Application" -Source $ParentScript command gives me a security error, "Access denied".
The users don't have administrative privileges so PowerShell is struggling to create a new source. I don't really understand this because most techy guides for the Event Log appear to indicate that any level of user can write to the Application log. Perhaps any user can write to this log, just not create a source within it?
I've looked online and one author appeared to suggest (unless I have misinterpreted) that creating an event log in registry could be an option: https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/00a043ae-9ea1-4a55-8b7c-d088a4b08f09/how-do-i-create-an-event-log-source-under-vista?forum=windowsgeneraldevelopmentissues
Unfortunately the code is not in PowerShell and I'm struggling to follow it.
My three-questions-in-one therefore are:
Can I create a new EventLog source in the registry using PowerShell?
If so, what commands should I be looking at and are permissions relevant (e.g. do I need to create a registry key then add perms to it?)
If so, can I write to this source in PowerShell without administrative privileges?
You can create a new Event Log souce with with the built-in cmelt New-EventLog something like there is a nice (even if somehow dated) post here
Full documentation for the cmdlet can be found here
Generally speaking yes you, well your user, should be able to write to the event log if memory serves a non local admin user should already be able to do so but I cannot test it right now anyhow you can red more here or read on server fault
Hope this can help a bit.
I'm trying to solve this problem since a long time, every execution I perform on TF.exe command, is throwing TF30063 exception, when i'm the admin and the only user of my TFS.
Problem: Try to execute this in a clean machine, without any visual studio user logged in on visual studio, IMPORTANT: also remove your user from windows credentials.
tf.exe workspaces /computer:mycomputer
This modal pops up prompting for credentials, but I need something to be run in a command window without user interference, so checking help I see that you could send /login:user,password
Then, again let's try with that in the command:
tf.exe workspaces /computer:mycomputer /login:myuser#outlook.com,MyPassword
And now, I get the following exception:
TF30063: You are not authorized to access xxx
BUT, and for the last, if I login on that popup (which I don't want to do because it will be a remote build service) suddenly all commands works fine.
What is the point of having /login command if is not useful here? is there a way to perform this login without prompt?
Thanks for the help!
It seems you are using VSTS, not on-premises TFS. Usually /login option can be used on on-premises TFS, we use the /login option to specify the Team Foundation Server user account to run a command.
If you want to use on VSTS, you need to get a OAuth token, and specify /loginType:OAuth. The command line is:
tf workspaces /collection:https://xxxx.visualstudio.com /loginType:OAuth /login:.,[OAuth token]
Add a screenshot:
I know it's been very long since this thread is opened but I recently experienced the same issue and resolved it by following the below steps. This maybe helpful for people who will get stuck with this issue in future...
Yes, I have faced the same issue and was able to resolve the issue finally :)
The problem is that tf.exe command with the switch "/login:username,password" works as expected with the onprem versions, however you have to use OAuth for saas version. Please find the below example command for saas version for your reference.
tf workspaces /collection:https://dev.azure.com/OrganizationName /loginType:OAuth /login:.,OAuthtoken
To generate the OAuth token you should be using the following article as a reference.
https://learn.microsoft.com/en-us/azure/devops/integrate/get-started/authentication/oauth?view=azure-devops
Hope this helps someone at some point of time :)
I have created a gMSA like this:
New-ADServiceAccount -name Cust00000 -DNSHostName Cust00000.domain.com -PrincipalsAllowedToRetrieveManagedPassword "IIS_IUSRS" -ManagedPasswordIntervalInDays 60
And life seems to be good. However, when I run
Test-ADServiceAccount Cust00000
This is what I get:
False
WARNING: Test failed for Managed Service Account Cust00000. If standalone Managed Service Account, the account is
linked to another computer object in the Active Directory. If group Managed Service Account, either this computer does
not have permission to use the group MSA or this computer does not support all the Kerberos encryption types required
for the gMSA. See the MSA operational log for more information.
I checked event viewer -> Application and Services Logs -> Microsoft -> Windows -> Apps -> Microsoft-Windows-TWinUI/Operational but this does not appear to be correct. Where (and possibly what) is the MSA operational log?
EDIT: For the overall issue, I had tried Install-ADServiceAccount but it wasn't working. I gave up on that and finally got it working (for a gMSA named Domain\sirdank$) with Set-ADServiceAccount sirdank -PrincipalsAllowedToRetrieveManagedPassword "$env:computername$" I've also had luck with passing "Domain Computers" instead of "$env:computername$".
Having a similar issue right now. I think the log you are looking for is in Event Viewer under Microsoft/Windows/Security-Netlogon/Operational log; you might see some 9001/9002 events (Task Category of MSA) which might give you some color on what is happening.
Got this from a recent TechNet blog post that describes troubleshooting gMSA account creation/testing issues. Take a look, it might be relevant to your overall issue: https://blogs.technet.microsoft.com/joelvickery/cannot-install-service-account-the-provided-context-did-not-match-the-target/
Alternate link (it appears the same post was cross-posted with a different title): https://blogs.technet.microsoft.com/runcmd/the-rc4-removal-files-part-1-whats-in-an-error-message/
All,
I am trying to use a certificate to authenticate against azure instead of using the Azure-AddAccount. So I did the following in an administrator powershell console, i followed the instruction located at http://azure.microsoft.com/en-us/documentation/articles/install-configure-powershell/ :
Get-AzurePublishSettingsFile
This prompted me to login and download the publishsettings file. I placed the file in the same folder as the powershell console is.
Import-AzurePublishSettingsFile "D:\Dev\Powershell\azure.publishsettings"
This command doesn't return anything. I am not sure if it worked, but if I put an invalid name it blows up so I assume it works.
Get-AzureStorageAccount
I get the error "Get-AzureStorageAccount : Your credentials have expired. Please use Add-AzureAccount to log in again." At this point I thought I imported my certificate and this should work, but it doesn't. Am I missing a step? I have multiple subscriptions, maybe thats the problem?
You still need to use Add-Account in addition to importing the publish settings file. Add-Account will prompt you for the user you wish to authenicate with when running certain commands.
Add-Account utilises a different authentication mechanism to the cert-based setup with the PublishSettings File and it necessary to use both in certain scenarios (such as yours).
I'm trying to run a powershell backup script as a scheduled task, and as a part of this I need to map a network drive (before copying the backup to the remote host).
Now, this was working when I had it like this:
NET use $RemoteDir $RemoteUser $BackupPass
But due to security concerns, I can't keep the password in plain text, or anywhere on the server. So, my hope was that, since it's run as a scheduled task, 'NET' would be able to "inherit" the credentials from the user running the scheduled task, so that it could be run like this:
NET use $RemoteDir
But it doesn't seem to work, when I log the error I get:
The password is invalid for <RemoteDir>.
Enter the user name for <RemoteDir>':
So, my question is: Is there any way to get this to work? I.e. having NET use the credentials that the scheduled job is running with? Or do I need to find another approach?
Edit: Forgot to mention, the user running the scheduled task is a domain user, and it has access to the remote.
Thanks!
Create a domain account. Assign the account permissions to the share and NTFS directory. Set the task to execute under the account you just created.
I dont have the solution, but a work arround.
You can store a password in a file locked down to say "domain admin" like the suggestion above and follow the directions on this link:
http://geekswithblogs.net/Lance/archive/2007/02/16/106518.aspx
Seems weird, I manage station users from scheduled task without any problem, so it is possible to use the credentials. Maybe the net use is just misbehaving, have you tried using New-PSDrive instead?