cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Active Directory Integration Details

A customer is looking for details on what information is sent to/shared with Active Directory in a typical App Broker implementation. I've explained that the direct connection(s) to App Broker are in order to 1) enable authentication for logging into App Broker and 2) allow App Broker to deploy to specific AD groups and add users to AD groups. I believe all of the other AD related tasks are accomplished via SCCM and extending the AD attributes there. Is that correct? Can I get any more details on what information goes to AD?

(1) Solution

I won't claim to be the authoritative expert in this area, but here's what I know (or at least believe to be true to the best of my knowledge)...

  1. App Broker does not "send" anything "to" AD except in the case you mention about updating AD security group memberships.  If you have enabled catalog items to use that feature and have granted the App Broker service account the appropriate permissions to write to AD (normally scoped to a specific container containing only groups used for App Broker), then App Broker will add users or devices to the specified AD security groups upon request submission, approval, or successful deployment (depending on how you've configured that catalog item).
  2. App Broker is a website running on IIS.  The default configuration leverages Windows integrated authentication in IIS to authenticate users of the system.  This is a function of IIS, not App Broker.  If you configure SSO using SAML, OAuth, or OIDC to an external identity provider, then that external identity provider replaces AD for authentication (the authentication method in IIS is set to "anonymous" and App Broker then forwards any unauthenticated requests to the IdP for authentication before allowing them to interact with the site).
  3. App Broker uses AD to get the ADGUID for each user to be used for authorization (i.e. what rights does the user have within App Broker).  App Broker will also get each user's group memberships and the corresponding group ADGUID's for the same purpose.  You can see this activity if you look in the logs contained in App Broker's UserLog folder.  App Broker also leverages OU membership for some functions of the site, but I believe the OU information is actually coming from the user/computer data sync process and not from a direct call to AD.
  4. App Broker syncs user/computer "discovery" information from the connected deployment systems.  This typically comes from AD through SCCM using AD User Discovery and AD System Discovery methods in SCCM but relies on SCCM's direct integration to AD rather than making calls directly from App Broker to AD.  These data sync queries can of course be customized to pull from an alternate data source, so technically, the user/computer discovery data could come from anywhere.  Item APT13 on this page of our product documentation spells out what AD attributes need to be collected in addition to the ones that are already collected by SCCM by default.  A full list of AD attributes that are pulled from SCCM discovery can be found in the default SQL queries on this page.
Anything expressed here is my own view and not necessarily that of my employer, Flexera. If my reply answers a question you have raised, please click "ACCEPT AS SOLUTION".

View solution in original post

(1) Reply

I won't claim to be the authoritative expert in this area, but here's what I know (or at least believe to be true to the best of my knowledge)...

  1. App Broker does not "send" anything "to" AD except in the case you mention about updating AD security group memberships.  If you have enabled catalog items to use that feature and have granted the App Broker service account the appropriate permissions to write to AD (normally scoped to a specific container containing only groups used for App Broker), then App Broker will add users or devices to the specified AD security groups upon request submission, approval, or successful deployment (depending on how you've configured that catalog item).
  2. App Broker is a website running on IIS.  The default configuration leverages Windows integrated authentication in IIS to authenticate users of the system.  This is a function of IIS, not App Broker.  If you configure SSO using SAML, OAuth, or OIDC to an external identity provider, then that external identity provider replaces AD for authentication (the authentication method in IIS is set to "anonymous" and App Broker then forwards any unauthenticated requests to the IdP for authentication before allowing them to interact with the site).
  3. App Broker uses AD to get the ADGUID for each user to be used for authorization (i.e. what rights does the user have within App Broker).  App Broker will also get each user's group memberships and the corresponding group ADGUID's for the same purpose.  You can see this activity if you look in the logs contained in App Broker's UserLog folder.  App Broker also leverages OU membership for some functions of the site, but I believe the OU information is actually coming from the user/computer data sync process and not from a direct call to AD.
  4. App Broker syncs user/computer "discovery" information from the connected deployment systems.  This typically comes from AD through SCCM using AD User Discovery and AD System Discovery methods in SCCM but relies on SCCM's direct integration to AD rather than making calls directly from App Broker to AD.  These data sync queries can of course be customized to pull from an alternate data source, so technically, the user/computer discovery data could come from anywhere.  Item APT13 on this page of our product documentation spells out what AD attributes need to be collected in addition to the ones that are already collected by SCCM by default.  A full list of AD attributes that are pulled from SCCM discovery can be found in the default SQL queries on this page.
Anything expressed here is my own view and not necessarily that of my employer, Flexera. If my reply answers a question you have raised, please click "ACCEPT AS SOLUTION".