Attempting to configure Security Group Provisioning of AD Groups

[jrobs3]

We recently moved to Adobe Enterprise IDs with authentication by Microsoft Azure. I had AD groups created for each Adobe Product which links successfully for entitlement. I'm having trouble with Security Group provisioning within AppPortal. I created a Catalog Item that only performs the provisioning as a test. The Security Group configuration 'sees' the Adobe AD Groups and I can point to the correct title no problem. Upon testing, the log comes back with an error: 

Inner exception: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) 

The AD Support Team didn't want the Service Account to have full reign in AD so the put the Adobe groups into an OU called Flexera Managed and assigned Modify rights to the Service Account for that container. 

I'm not sure if he problem is with AppPortal configuration or the AD permissions of the Service Account. The AD Support Team says its got to be AppPortal but all other aspects of the AD integration (Computers & Users, etc...) works as expected. 

[TeriStevenson]

I don’t remember what error we got when we first configured the catalog items to add the user to the security group but we eventually found the cause was the displayname attribute didn’t have a value. App Portal uses the CN or SAMACCOUNTNAME attribute when it looks for the security group. We finally got an exception internally to have a OU specific for groups App Portal was adding to and to have the displayname attribute populated. Not sure if that is what you’re experiencing but maybe something to check on your groups

[CharlesW]

If Teri's suggestion does not seem applicable to your situation, you might try running the following query against the App Portal DB, to see if this helps:

IF NOT EXISTS (SELECT [KeyName] FROM [WD_AppSettings] WHERE [KeyName] = 'HasUntrustedDomains')
INSERT INTO [WD_AppSettings] ([KeyName], [Value]) VALUES ('HasUntrustedDomains', 'True')
ELSE UPDATE [WD_AppSettings] SET [Value] = 'True' WHERE [KeyName] = 'HasUntrustedDomains'

Once you have run the query perform an iisreset. This setting basically tells App Broker to make some different AD calls, and frequently resolves certain issues.

NOTE To revert the behavior run the following and perform an iisreset:
update wd_appsettings set value = 'False' where keyname = 'HasUntrustedDomains'

[jrobs3]

Just got out of my meeting and no luck with the displayname attribute. I've submitted a Change Request to attempt Charles' suggestion on Monday. Fingers crossed.

[jrobs3]

Charles, we ran the script you provided and reset IIS. Same result. I've attached redacted copy of the log. Any other ideas? 

[CharlesW]

I'm inclined to believe that this is simply a permissions issue at this point... Th flag that I had you set tells App Broker to try a different approach to add the user to a group.. As this is failing in the same way as was originally happening seems to indicate an account problem.. I'd be curious to know if you can add a user to the group using something like a powershell script.. For example, using the command Add-ADGroupMember.. The following URL details the command..

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee617210(v=technet.10)?redirectedfrom=MSDN

Obviously, you would want to specify the service account for the credential when trying this.

I should note that this is not the way that App Portal is trying to add the user to the group, but if this fails, then we most definitely have a permissions issue.

[jrobs3]

Charles, the AD Admin was able to add my account to the Security Group using Active Directory Users & Computers this morning logged in as the FlexWeb Service Account. Is there a config somewhere that should contain the Service Account credentials that may not currently? 

[CharlesW · Accepted solution]

No, there is no config file where credentials could be stored.. According to the log excerpt you provided, "integrated" credentials are being used. This means that it is the ESD Service account being used, which I assume is "FlexWeb"? I'd be very curios to know if the powershell command works as well.. I've no idea if using AD users and computers behaves in the same was as calling an API.. 

[jrobs3]

Charles,  That was the issue. I assumed the process was supposed to use the FlexWeb Service Acccount but in fact it's using the FNMS Service Account which is set up as the local admin on the WebServer and running the ESD Service. That was the key. Thank you for clarifying. Everything works as expected now. Thanks again!

[jrobs3]

Thank you. I'm meeting with the AD Admin this afternoon. I'll run this past him. Greatly appreciated!