Can gMSA accounts be used across two trusted domains? Say there is a DomainA which has gMSA account, and security group that is allowed to retrieve password for the gMSA account. And there is a server that belongs to DomainB that is part for DomainA\SecurityGroup.
When running Install-ADServiceAccount, I get:
Install-ADServiceAccount : Cannot install service account. Error Message: 'An unspecified error has occurred'.
I can retrieve the account from DomainA using Get-ADServiceAccount by specifying -Server parameter. Then pipe that into Install-ADServiceAccount and get above error.
When piping the account to Test-ADServiceAccount I get this:
Test-ADServiceAccount : Object reference not set to an instance of an object.
No, at least not that I've found. I think there's something in the API that makes it send the request for the password to only its own domain's DCs.
I have used gMSA accounts across a domain trust. The gMSA principal needs to be a group in the same domain, but as long as the group is type Domain Local, you can add computers from the other domain as members to that group, and they are then able to retrieve the password successfully.
Related
I have two service accounts svc-a and svc-b created in the same domain under same OU. Recently I upgraded my Windwos Web server with latest security patch, where these two service accounts are used to run two different IIS websites.
Post patching, svc-a fails to fetch AD group members for any group. While svc-b can still do that.
The error I get with svc-a is,
get-adgroupmember : Either the target name is incorrect or the server
has rejected the client credentials. At line:1 char:1
get-adgroupmember acifeesadmin -server au.amp.local
+ CategoryInfo : SecurityError: (acifeesadmin:ADGroup) [Get-ADGroupMember], AuthenticationException
+ FullyQualifiedErrorId : ActiveDirectoryCmdlet:System.Security.Authentication.AuthenticationException,Microsoft.ActiveDirectory.Management.Commands.GetADGroupMember
One of the suggested fix I found on Google was to enable RC4_HMAC_MD5 encryption method, which when done, svc-a account can fetch AD group members successfully.
Enabling RC4_HMAC_MD5 encryption type is not a feasible solution for us as our Group policy wipes out this change and also it being an older encryption type, is more vulnerable to attacks.
Based on the suggestion from this excellent blog on Kerberos encryption types
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/decrypting-the-selection-of-supported-kerberos-encryption-types/ba-p/1628797 I have enabled AES 128 and AES 256 encryption types on the service account svc-a
The service account svc-a still cannot fetch AD group members and fails with the same error.
The only way it can fetch AD group members, is when I enable RC4_HMAC encryption type on the Web server(which I don't want to)
In summary,
Two similar service accounts in a domain used in a window web server to run IIS websites
Post security patch installation on the Web server, one of the service account fails to fetch AD group members.
Enabling RC4_HMAC encryption type on the Web server fixes the problem but this is not a feasible solution as our group policy wipes out the change.
Making changes to the service account on AD, to allow AES 128 and AES 256 encryption types does not help
I have tried resetting password for svc-a, that too did not help.
Does anyone know what else should I be trying or has insights on why this doesn't work?
This has been fixed. The service account's password was reset before the RODC was created and hence DC kept issuing service tickets with older encryption method. Resetting the password twice after a gap of 10 hours fixed the issue.
I am using powershell to get audit fail events 4625 and 4771 from the Domain Controllers. Most of these are 0x18 Status. Now i understand the events with usernames (don't end in a $) as having bad passwords from a machine. Most of the google examples show 4771's from users.
What i want to understand, is what it means when it is coming from a machine?
i.e. surely it is an account on the machine which has an issue, how does a machine have a bad password? And if it can, how does one find out what the issue is ?
Active Directory is an identity management system, and so anything that authenticates with Active Directory needs an "identity" of some sort. Since computers themselves can be joined to a domain and must authenticate against it (with a username and password via Kerberos the same as a regular user logon), they have a username. The AD machine account username is the computer's DNS hostname followed by a dollar sign, for example: Desktop-AB123$
Since every computer in the domain must authenticate against the domain with a username and password, it is possible for that authentication to fail. And it can fail for all of the same reasons that a regular user logon can fail: unrecognized or misspelled username, incorrect password, wrong domain or UPN suffix, or any number of authentication errors.
Event ID 4771 indicates a Kerberos preauthentication error and status 0x18 (usually) indicates a bad password. Source.
Machine accounts renegotiate their password automatically with the Domain Controller when they connect to the domain. If a domain-joined workstation is unable to communicate with a domain controller long enough for the password to expire, it will not be able to log in and you will get a failed logon for that computer's machine name. The computer will need to be rejoined to the domain (or have its password reset using Reset-ComputerMachinePassword and a domain admin credential). The same is also true if a domain controller is unable to communicate with the PDC Emulator. This will be the most common type of error that will lead to failed machine account logins. The second most common will probably be due to computers being renamed while unable to contact a DC, changing the computer's logon username without updating AD.
Beyond password expiration or computer renames, you have to start looking deeper for root causes. These are likely going to be Kerberos negotiation errors caused by services attempting to authenticate in order to perform certain actions. Note that the authentication error does not necessarily occur at service start and may occur when the service is accessed or triggered by another application. I recommend reviewing my question & answer in ServerFault regarding one such example where a server's DNS name didn't match its NETBIOS name, which caused Kerberos authentication to fail and fall back to NTLM.
As that ServerFault question illustrates, tracking down the root cause of a failed machine logon, once you've ruled out username and password errors, can be extremely difficult. Your first step should probably be to enable Netlogon debug logging and then searching the netlogon log file for your failure events. You can also search the SYSTEM event log for any events related to services failing to start. After those two starting points you're basically on your own and will need to develop some advanced troubleshooting and investigation skills to track down the root cause.
One final note, your question is not exactly related to programming or software development, so SuperUser or ServerFault might be a better place for questions such as this in the future. ServerFault is geared towards professional sys admins working in production environments while SuperUser is more geared towards hobbyists, enthusiasts, home servers, and DIYers.
I'm building a DAG that would upload files to Google Drive at the end, utilizing Airflow's GoogleDriveHook. As this is executed using a service account, I use my email as the delegate_to parameter, and enabled domain-wide delegation beforehand. Scope for the email is https://www.googleapis.com/auth/drive.file.
DAG would run just fine if the connection's scope is just that, however, since I use the same Airflow connection for other DAGs that utilizes other GCP services, I would have to use multiple scopes for that aforementioned connection.
For some reason, it would fail during upload on multiple scopes, spewing out:
google.auth.exceptions.RefreshError: ('unauthorized_client: Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested.', '{\n "error": "unauthorized_client",\n "error_description": "Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested."\n}')
Though having multiple Airflow connections is not much of a deal-breaker, I guess at this point I'm just curious to why this happens (Airflow 1.10.9)?
I use my email as the delegate_to parameter
Did you use a gsuite domain email?
Did you set up domain wide delegation in GSuite?
Delegate to only works with Gsuite domain emails.
If you want the service account to be able to access you personal non g suite google account. Then you will need to share a directory on your persona drive account and grant the service account access to that directory like you would any other user by sharing the directory with it.
Once files are uploaded they will be owned by the service account you will then need to ensure to insert permissions for that file so that your personal account will then have access to the files.
Using a server application with C#, how is it supposed to work when accessing users in the same domain if the authentication is only possible using:
OAuth2Authenticator interface?
I'm able to access the admin of the domain's Drive, but I'm missing the 3 legged OAuth in 2.0.
Looking at this description found at this link: https://developers.google.com/drive/delegation
Since this is not executed as a Service, and is not using Google Apps and cannot then
access: https://www.google.com/a/cpanel/mydomain
Also the IP is not known from where the machine running the server-application.
Currently I'm using: "Client ID for installed applications", and it works. But what I need is to also store files in other users in the same domain.
A other solution that works temporarily is to first store them at the admin domain account and then move them to the user domain account. But this removes the possibility to direct it to a parent/folder at the end user's drive. It will always be stored in root for that end user.
Basically what I want is following:
A Server application is running on a local machine (admin domain account can be used)
The application upload files to different users that are in the same domain, but with their own email address and also then have their own Drive.
Yes, you can do that through 2 legged oauth, which can provide domain-wide authorization.
Here are some links for your reference:
https://developers.google.com/gdata/docs/auth/oauth#2LeggedOAuth
http://support.google.com/a/bin/answer.py?hl=en&answer=2538798
I have an application server (webservice or remoting, not yet decided) on a remote machine and a client on the same domain. I want to authenticate the user as a domain user on the server.
I can ask the user to enter their Windows username/password and send those to the server and get the server to check them against Active Directory but I would rather not. Is there any way I can get the client to send some kind of token which the server can then use to identify which domain user is sending it a request? Obviously I want to protect the server against someone sending a fake user ID and impersonating another user.
Clarification
The client on computer A will communicate with the server on computer B. I think I will probably using .NET remoting for this communication. On the server I merely need to know the ID of the user on computer A; if the app on computer A must send the ID I need to be sure that it hasn't sent the ID of a different user.
I don't need to impersonate the other user, I merely need to know (for certain) who it is.
Are you saying that the client communicates against your server, and you need to use the client's privileges at a third server? That scenario describes The Double-Hop Problem. The blog most describes it in detail, and what can be done to circumvent it (domain modifications).
[...] you can get around the problem and use proper delegation if you set up your network to use Kerberos and set up the web server in question as trusted for delegation.
Added:
I know of no way you can identify the user on computer A. Would it be enough if it was just the user executing your program? You could use windows authentication in a domain scenario, but that would only give you the privileges used by the program to authenticate, which may differ from the actual evil user in front of the keyboard.
Added:
Your comments to this post indicates that windows authentication with impersonation would work for you. Check http://community.bartdesmet.net/blogs/bart/archive/2006/08/26/4277.aspx for code examples.