I'm trying to load the user profile (using LoadUserProfile - http://msdn.microsoft.com/en-us/library/windows/desktop/bb762281%28v=vs.85%29.aspx) but the API fails when the user is a windows domain user.
The application runs with an Administrative user (not System Account, the same code in a service running as System Account works).
The same code works if the user I want to access is a local user.
Is there any limitation for the LoadUserProfile and Windows Domain User? LoadUserProfile returns Access denied. Are there any policies which limit the API?
My code does the following:
LogonUser
LoadUserProfile - This fails with access denied.
ImpersonateLoggedOnUser
I'm not sure if the issue is 100% related with my code, because if I run
runas /user:domain\user cmd.exe
I got the same failure:
"Access denied"
So it seems that there are policies which control the behavior of Domain users.
Related
I followed all the mentioned steps but couldn't get it to work with "Active Directory Password Authentication" for AD principal which is a contained user in my SampleDB. I get this error:
Cannot connect to sql01.database.windows.net.
ADDITIONAL INFORMATION:
Failed to authenticate the user user#customDomain.com in Active
Directory (Authentication=ActiveDirectoryPassword).
Error code 0xCAA20003; state 10
ID3242: The security token could not be authenticated or authorized.
(Microsoft SQL Server, Error: 0)
We are using Ping Federate as our federation provider.
To my surprise, "Active Directory Integrated Authentication" works for the same user. Do we need to open some firewalls or ports at our on-prem environment to make it work?
Please create a support case. ADAL.DLL had issues in the past with Ping Federate so the support team would be the best to look into it
I'm trying to fetch users from azure active directory using graph api. I've tried many ways, none of them worked, but let's stick to simplest one - using this instruction and some app to make http requests (I'm using postman) I'm able to obtain autherization token with no problem. After that I want to get users list using https://graph.microsoft.com/v1.0/users, passing token in header. Instead of the users list I get "Insufficient privileges to complete the operation." This error message is very confusing to me because app registration has now all possible permissions and service account that owns this app is in role of Global Administrator, so I believe there aren't any more privileges that this app could get.
Task of the application I'm developing is to merge users data from few companies and display users list on web page hosted on azure account of one of them. What's even weirder for me in all of this, is that for one these domains accesing users data using graph api actually works, so logically configuration isn't set correctly everywhere, but I don't really know what can be difference that makes one them work and others fail on "Insufficent privileges error".
As you are integrating AAD in app only applications, as the description at https://graph.microsoft.io/en-us/docs/authorization/app_only:
After you register the application, configure the application permissions that your service or daemon app requires.
So, firstly, you may check out whether you have configured the correct permission on Azure portal:
According to your error message:
Insufficient privileges to complete the operation
And the application permissions require that your application has admin privileges. You can try to upgrade the role of the AD application you use to a administrator permission. Run the following commands in PowerShell:
Connect-MsolService
$ClientIdWebApp = '{your_AD_application_client_id}'
$webApp = Get-MsolServicePrincipal –AppPrincipalId $ClientIdWebApp
#use Add-MsolRoleMember to add it to "Company Administrator" role).
Add-MsolRoleMember -RoleName "Company Administrator" -RoleMemberType ServicePrincipal -RoleMemberObjectId $webApp.ObjectId
I had to change the admin password as it had expired via RDP. The server was working fine after the change.
Later I disconnected the session, and started it again, now we are getting the following error message:
An authentication error has occurred.
The Local Security Authority cannot be contacted
Remote computer: **.cloudapp.net
This same error keeps coming up even after 2 server restarts. The password is defiantly correct as typing a different password gives a "Password Incorrect" error.
There is no other way for us to access this server.
I found the answer here.
Your machine should still have a local administrator account (e.g. MachineName\Administrator), in which case you can login with the administrator account. In the RDP login prompt, you'll need to put the full user account (e.g., "MachineName\Administrator" where MachineName is your computer's name, otherwise it will default to "PreviousDomainUsed\Administrator").
This happened to me with an Azure VM because the domain administrator account I was using had an expired password and the Azure VMs enforce Network Level Authentication, which prevents you from changing the password through RDP. I was able to update the password by logging into the domain controller's VM, but the VM I couldn't log into didn't receive the update because the DNS settings were incorrect. I RDP'd into the faulty VM with the local administrator account, updated the DNS settings and ran "gpupdate" in a Powershell command prompt and everything began working again.
Hope this helps.
I had same issue with local admin account and specifying user account as "machine name\Administrator" still did not work. There was only local admin account in Azure VM so I needed to solve this issue for local admin account.
I could reset password for local admin account by following step then now I can log in to Azure VM by local admin account.
Open Azure Portal web site.
Click "Virtual Machine" then click virtual machine name which issue having in the list.
Dash board for selected virtual machine is shown. Then click "Reset Password".
Following screen is displayed so specify local admin account name nand password, then click Update.
This uses the VMAccess extension to reset the built-in administrator account and reset the Remote Desktop service configuration. Learn more
Mode
You can perform a password reset, which will also reset the Remote Desktop service configuration, or choose to reset the configuration only.
Reset password
User name:
If you provide a different user name, then the built-in administrator account with be renamed. Also, the account will be enabled if it's currently disabled. (The name of local admin account is shown as default)
Password
Confirm password
here is an answer if you need it yet.
http://social.technet.microsoft.com/wiki/contents/articles/18710.troubleshoot-azure-vm-by-attaching-os-disk-to-another-azure-vm.aspx
I'm using System.DirectoryServices to list the status of websites running on a server. Currently I'm using impersonation of an admin account for this to run but I'd prefer to have a specific user account with the bare minimum privileges.
Can anyone point me in the right direction?
From the MS documentation, it looks like DirectoryServices just delegates calls to IIS:// directory entries to the IIS ADSI provider. The IIS ADSI Provider docs state that you need to run it as a member of the local administrators group:
When using ADSI to configure IIS,
ensure that the user account of the
person running the script is a member
of the administrators group or use
LogonAdmin to run the script under the
credentials of an administrator.
I have come across a strange problem in one of our applications on win2k8/Vista x64 with UAC enabled. It is a process which hosts the UI for our service and runs in the context of the logged on user.
When logged in as a domain user who is a member of the "Administrators" group, writing to the registry under HKLM fails due to UAC with access denied.
But when logged in as the local "Administrator" account (non-domain) then writing to the registry succeeds.
Both accounts are adminstrators - is there a distinction between domain and non-domain accounts with UAC? What gives?
Thanks... from further reading it seems that it does affect vista as well:
"Being part of the Local Administrator Group doesn't provide the same access as the Local Administrator Account (the same also applies to Windows Vista). With Windows Server 2K8, the administrator access token is split into 2 tokens when logged into the server. One of these is an administrator token and the other a standard user token. During the logon process, authorization and access control components that identify an administrator are removed, leaving a standard user token. The standard user token is used to start the desktop and, therefore, all applications that start run as a standard user."
not sure if this applies but by holding shift+control you can start applications in admin mode, even if youre logged in with a domain admin account. you can then use the application as a local admin