When I was in MMSMOA, I met Adam Gross. I have known him already in Twitter, but it’s was really nice to meeting him in person. Adam has wrote many excellent posts about AdminServcie, please read his posts for more information, I won’t go to the details here talk about what it is and how to use those cool queries. I will just more focus on the “over internet”
I spent three days checking how to use ConfigMgr AdminService over internet, first idea was use On-Premises data gateway, then use Logic App, Flow or PowerBi make REST API call via data gateway. It did work in TP1902 and CB1902, but it stop working after I upgrade my Technical Preview 1902 to 1906 and 1907. So I reach out to ConfigMgr Product Group ask for more details. Special thanks for Prabagar Ramadasse and Ehsan Omidi from Microsoft, they explain to me what has changed and improved in AdminService, they are my heroes, saved my day!
1902 supported only one of the auth methods on the same SMS provider machine based on how it is configured. It supported only AAD authentication or only Windows authentication per SMS provider machine.
1906 support 2 listening endpoints on the same SMS provider machine. You should have seen this changes from 1906TP. it is not that SCCM AdminService endpoint is not supporting NTLM windows authentication. NTLM windows authentication is supported as a fallback when using Negotiate. Negotiate will always start from secure authentication first if possible, before falling back to NTLM. But client can’t start from NTLM and only use NTLM.
Turns out, I don’t need on-Premises data gateway at all. All I need is Cloud management gateway (CMG)!
- The server that hosts the SMS Provider requries .NET 4.5.2 or later
- Enable the SMS Provider to use a certificate, Enhanced HTTP or PKI
- The account you are going to use AdminService, it need to be synced to Azure AD.
- First you need setup cloud management gateway. If want to build Flow or Logic custom connector, then you will need use public certificate to setup your cloud management gateway. But if you only want use it with PowerShell, you can use your Self-Signed certificate.
- You need to configure allow cloud management gateway traffic for AdminService.
Let’s say my SMS Provider server name is CM01.ZIT.local, there is actually two authentication endpoint for AdminService. If the API call is coming through cloud management gateway, it automatically redirect to token authentication endpoint:
- Endpoint for on-premises windows authentication:
- Endpoint for all bearer token authentication methods, which includes AAD token:
Cloud management point Endpoint
This is the endpoint for over cloud management gateway, it use bearer token, which includes AAD token :
You can find your endpoint address from SQL query or registry.
- SQL query:
select ExternalEndpointName, ExternalUrl from vProxy_Routings where ExternalEndpointName = 'AdminService'
Create Azure Application
When we setup cloud management gateway, we first created cloud management service in ConfigMgr, it created two applications in Azure, one Native Client app, another one is Web API app. If you were using default settings, the native client app is “ConfigMgrClient”, and the Web API app is “ConfigMgrService”. Because I don’t want to modify these default apps, I will make a new Native Client app, grant it permission for “ConfigMgrService” app.
- Go to your Azure Portal, Click on Azure Active Directory, click on App registrations, then New registration
- Input a name example AdminService. Supported account types choose organizational directory only. You can also use any organizational directory, if you manage multiple tenants and wants use this app to all your tenants.
Redirect URI, choose Public client (mobile & desktop), and value as urn:ietf:wg:oauth:2.0:oob
- After registered this app, go to Authentication, change Default client type from to Yes, so that this will be a public native client
- Click on API permissions, choose your “ConfigMgrService” app from APIs my organization uses.
NOTE: I am using ConfigMgrServiceTP as the app name in my test lab, so in this blog post you will see me using ConfigMgrServiceTP
- Choose user_impersonation, then click add permissions
- Click on Grant admin consent, because the user account is going to use this app is properly ConfigMgr Admins, and they don’t have permission to use this recourse by default, so you must grant them permissions.
For example, I want to query SMS_R_User, we will use this query in AdminService via cloud management gateway:
There are few variables that you will need to change in the scripts
- $clientId , change this to your own AdminService app client ID, you will find it in Overview
- $TenantID, change this to your own tenant ID, you will also find this in Overview
- $resourceAppIdURI, find your ConfigMgr Service app, go to Expose an API, you will find your Application ID URI
- $url, Change this to your own AdminService cloud management gateway query endpoint.
After you run the script, you should be able to see some results.
You should see in AdminService.log, that authentication is redirected to:
Run CMPivot in Postman using cloud management gateway (thanks for those queries from Adam Gross’s blog post )
Get CMPivot resutls via cloud management gateway
Hope you like this!
Hi, may I have a question?
We are currently developing an integration from our product to SCCM and we just need to read some HW Inventory data over the internet.
Our windows service is authenticated using token gained by grant “Resource Owner Password Credentials”. I know, it’s not recommended flow, but it works fine. Unfortunately, one of our custommers is using federation services for their accounts and ROPC doesn’t apperantely work for federations.
Therefore, we’d rather like to use Client Credentials flow to get a token, but this is a scenario without user context.
So here are my two questions?
1. Is there a way to access AdminService data without a user context?
2. Is there a way to get an access token with user context from windows service for account that is under ADFS synchronization?
Thank you for your answers.
Hello, as far as I know, admin service needs user context, because it needs identify if the user has permissions for ConfigMgr.
I think ADFS shouldn’t have any impact on this, as long as the user account has permissions to ConfigMgr, and it’s synced to Azure, UPN name need to be same in AD and AAD (should use custom public domain), and CMG should use public certificate as well.