Hello everyone, I am trying to carry out an active directory integration through GMSa, but I have doubts about it, this being the first…
If GMSa, it is an exclusive technology for Windows Server machines, why does it give the option to use it in the forest configuration section? (When, according to the documentation, this section is to perform aggregation tasks to the global catalog from the VAs, machines that are Linux)
Then there is the Domain Settings configuration, whose account is the one established and is responsible for carrying out all aggregation or provisioning operations in the domain, and finally the configuration at the IQService authentication level, where you specify the machine whose service is installed and it needs a user to authenticate, not knowing if it is the same UPN used in the GMSa account, because it is not specified which formats are supported.
Any input is welcome, as I’m not the only one who is having trouble getting the most out of this new feature.
By default, the Active Directory connector is divided into two different components:
Aggregation - Completed only by the VA using basic commands to search the directory.
Provisioning - Handed off from the VA to the IQ Service and uses the ADSI/.NET libraries.
My understanding is that when you switch to using gMSA that the IQ Service is used both as a part of aggregation and as a part of provisioning. If you go on through the setup instructions, it will redirect you back to the additional configuration that shows that you must setup the IQ Service logon user to be able to retrieve the specific passwords for the gMSA accounts. See:
Nice to meet you, Alicia, I wanted someone to corroborate that same statement, that these tasks were delegated to IQService, since knowing something about this technology I assumed it, but without having official confirmation with a manufacturer’s case opened in parallel.
I will try to do it in reverse, because the installation of IQService consists of all the permissions required by the manufacturer, including, additionally, the service account of being a member of the machine’s Administrators group, this account is explicitly defined with the Same permissions flag to rule out inheritance issues in the regedit, the certificate keys used and the folder.
The machine service has defined and running the log on as with the gmsa, running. And the accounts in forest, domain and IQService settings, with a normal account domain.
To also put into context, I have defined in the IQService client authentication the users of the gmsa account, with the formats that I indicated, and the domain account that is currently operating to get out of trouble:
DOMAIN\user → Normal domain account, with operation permissions
DOMAIN\name_GMSA_user → Format that I highly doubt, because this is defined to work but to rule out cause of failure
[email protected] ->Used for the corresponding Kerberos authentication and vice versa since this technology requires the use of SASL authentication
It did not work but I have discovered that the negotiation of the Kerberos ticket is carried out from the VAs, but later when I access the Domain Controller log, in the Directory Service section, it tells me that the consulted route does not work. Thinking that it is the same route where I define the visibility of groups and users, with which it works through basic authentication.
I assume that at the certificate level the RootCA or the intermediate one must be enough