search

MSEndpointMgr / ConfigMgr

Microsoft Endpoint Configuration Manager scripts and tools
628 stars 282 forks source link

Unable to Dynamically Download Drivers over CMG #279

Open Jhanno opened 3 years ago

Jhanno commented 3 years ago

Hi all,

I'm on the latest version of the Driver Automation Tool (6.4.9) and using the latest Invoke-CMApplyDriverPackage.ps1 (4.0.5).

I'm able to download drivers successfully while on the Intranet, but havent had any success over the Internet (Cloud Management Gateway).

Here's the logs that I see for ApplyDriverPackage.log while on the Internet via CMG:

[ApplyDriverPackage]: Apply Driver Package process initiated

The task sequence essentially just gets stuck at this point. Any ideas?

GbCaa commented 3 years ago

I'm having the same problem. If you check the SMSTS.log, you'll see an error message was captured by it: WARNING: Failure to acquire access token. Response with access token was null

... If you look at the code of the PSIntuneAuth module, it's in there. So I think something broke in the PSIntuneAuth module but I could be wrong.

Edit: I figured it out!

On line 812 the Resource parameter has "https://ConfigMgrService" ... I changed that to the URL my CMG App Server is using and things started working.

tonycontorno commented 3 years ago

Hey there, I'm experiencing the same problem here. Could you elaborate on the URL you used for your CMG App Server? Did you go down to /AdminService/wmi or was there another URL you were using?

GbCaa commented 3 years ago

Hey there, I'm experiencing the same problem here. Could you elaborate on the URL you used for your CMG App Server? Did you go down to /AdminService/wmi or was there another URL you were using?

In Azure "App Registrations", find the one that points to your SCCM server for Cloud Management Gateway... in the overview, the "Application ID URI" is the URL I was using for the -Resource parameter.

tonycontorno commented 3 years ago

Ah, thanks. That could explain part of our problem. I don't have that field filled out at all. I suspect something was missed...

Jhanno commented 3 years ago

Hey there, I'm experiencing the same problem here. Could you elaborate on the URL you used for your CMG App Server? Did you go down to /AdminService/wmi or was there another URL you were using?

In Azure "App Registrations", find the one that points to your SCCM server for Cloud Management Gateway... in the overview, the "Application ID URI" is the URL I was using for the -Resource parameter.

I also have dont "Application ID URI" filled out.... was that in the documentation? I cant seem to find that step. How did you set this up?

GbCaa commented 3 years ago

Hey there, I'm experiencing the same problem here. Could you elaborate on the URL you used for your CMG App Server? Did you go down to /AdminService/wmi or was there another URL you were using?

In Azure "App Registrations", find the one that points to your SCCM server for Cloud Management Gateway... in the overview, the "Application ID URI" is the URL I was using for the -Resource parameter.

I also have dont "Application ID URI" filled out.... was that in the documentation? I cant seem to find that step. How did you set this up?

It's not in the documentation. I'm betting the author assumed you followed their documentation for setting up a Cloud Management Gateway in which case the -Resource would be the same name. On line 812 of the Invoke-CMApplyDriverPackage, I changed my resource to the name I used when I created the Application ID URI:

$Script:AuthToken = Get-MSIntuneAuthToken -TenantName $TenantName -ClientID $ClientID -Credential $Credential -Resource "https://cmg/ConfigMgrService" -RedirectUri "https://login.microsoftonline.com/common/oauth2/nativeclient" -ErrorAction Stop

vbateman commented 3 years ago

So by default your CMG app will be https://ConfigMgrService (unless you changed - which I didn't) And line 812 (actually line 814 in the latest script) will refer to that. But I'm having no luck getting past this in the log: "Attempting to retrieve authentication token using native client with ID: ClientID", it eventually times out.

Anyone else got this working using all the defaults when creating the Web App??

TacII commented 3 years ago

So by default your CMG app will be https://ConfigMgrService (unless you changed - which I didn't) And line 812 (actually line 814 in the latest script) will refer to that. But I'm having no luck getting past this in the log: "Attempting to retrieve authentication token using native client with ID: ClientID", it eventually times out.

Anyone else got this working using all the defaults when creating the Web App??

Yes, I had the same problem. Make sure that the account you're using to access the Web App doesn't have MFA enabled. You should be able to verify that everything works by running this command. Replace your Tenant Name and ClientID of course.

Get-MSIntuneAuthToken -TenantName "yourtenant.onmicrosoft.com" -ClientID "12345678-1234-1234-1234-123412341234" -RedirectUri "https://login.microsoftonline.com/common/oauth2/nativeclient" -Resource "https://ConfigMgrService" -verbose

You will get a popup that asks for your service account credentials. Be sure to enter it with the full domainname.

JackS369 commented 3 years ago

Hi @TacII, when i run the above command on the client machine, I'm getting the error of "Warning: Failure to acquire access token. Response with access token was null". Any advice on this? @GbCaa @Jhanno is It working for you now?

GbCaa commented 3 years ago

Hi @TacII, when i run the above command on the client machine, I'm getting the error of "Warning: Failure to acquire access token. Response with access token was null". Any advice on this? @GbCaa @Jhanno is It working for you now?

Yes and with the latest script by added in to the list of Dynamic Task Sequence Variables MDMApplicationIDURI=https://cmg/ConfigMgrService (my CMG as found in "App Registrations")

If you're still stuck, check the Sign-Ins & Audit logs of your service account in Azure AD. Hopefully it will give you a clue.

gregor79 commented 3 years ago

Hey there, I went through above suggestions and still experiencing same issue. Hardcoded Resource URI to point to my CMG Application ID (line 833 in script version 4.1.0). I also added MDMApplicationIDURI as task sequence variable but no luck. Account is excluded from MFA and I can successfully acquire access token when manually running the script (as the account) provided by @Tacll. I don't see any errors in Azure sign-in or audit logs for the account. I noticed the failure in task sequence happens more less after 6 secs between token is requested and when token cannot be obtained. Is there a way to increase the timeout?

Any other ideas?

Edit:

I think I figured out why the token cannot be retrieved. We block legacy authentication at ADFS level so it's a no go for us. ................... VERBOSE: Attempting to locate AzureAD module on local system VERBOSE: AzureAD module detected, checking for latest version VERBOSE: Latest version for AzureAD module was detected, continue to aquire authentication token VERBOSE: Currently running in parameter set context: AuthCredential VERBOSE: Attempting to acquire access token using legacy user delegation with username and password WARNING: Failure to acquire access token. Response with access token was null

Is there a way to use modern authentication in the script when external endpoint is discovered? Perhaps run as azure automation account, etc ?

Any suggestions much appreciated.

MarkusMory commented 3 years ago

Good morning,

@gregor79 I got exactly the same problem at one of my customers. If I run Get-MSIntuneAuthToken -TenantName $TenantName -ClientID $ClientID -Credential $Credential -Resource $ApplicationIDURI -RedirectUri "https://login.microsoftonline.com/common/oauth2/nativeclient" -Verbose the command will fail because of the basic (legacy) authentication. If I run the same command without the -Credential parameter it will use the modern authentication. This way the authentication works correctly.

Enabling basic authentication seems to be a workaround but if I remeber it correctly MS is going to block basic authentication automatically https://azurescene.com/2021/01/18/an-update-on-legacy-authentication/

gregor79 commented 3 years ago

@MarkusMory Thanks for your comment. It still doesn't work for me though when I remove -Credential parameter. As script runs in local system context when acquiring access token it is presented with the modern auth prompt. How do I pass on credentials in a script?

VERBOSE: AzureAD module detected, checking for latest version VERBOSE: Latest version for AzureAD module was detected, continue to aquire authentication token VERBOSE: Currently running in parameter set context: AuthPrompt VERBOSE: Attempting to acquire access token using user delegation

MarkusMory commented 3 years ago

@gregor79 Sorry for the late response. I think you can't use credentials here. There are two other ways for authenticating against an Azure App via Script. You can use a certificate or a client secret (https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal#authentication-two-options).

I will test the secret key method as soon as I have time for it.

bbrownchg commented 3 years ago

@gregor79 Sorry for the late response. I think you can't use credentials here. There are two other ways for authenticating against an Azure App via Script. You can use a certificate or a client secret (https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal#authentication-two-options).

I will test the secret key method as soon as I have time for it.

I was able to modify the script to use a client secret to generate a token, which the logs show was successful. After that, though, I get a 401 unauthorized when trying to query for drivers. Trying to troubleshoot that right now.

MarkusMory commented 3 years ago

I guessed that this would be a problem. You can authenticate against the Azure app but not against the MECM Admin Service with the secret key. Maybe @maurice-daly has an idea how to fix that.

bbrownchg commented 3 years ago

I guessed that this would be a problem. You can authenticate against the Azure app but not against the MECM Admin Service with the secret key. Maybe @maurice-daly has an idea how to fix that.

Yea, that makes sense and is pretty much what I figured yesterday. I did go back to the drawing board though and figured out that if I removed the -Resource $ApplicationIDURI line from Get-MSIntuneAuthToken that I'm able to generate a token using the credentials, but I'm still running in to the 401 on the actual query. Waiting for my Azure AD logs to update to see what the issue is.

bbrownchg commented 3 years ago

Well I still haven't made any progress here. I figured out my application ID URI was wrong and fixed that, am able to generate a token while specifying that but I'm still getting a 401 unauthorized trying to query over the CMG. The same account can query on the internal network no problem. The confusing thing to me is the external query doesn't even show in the AdminService.log file. Probably gonna construct a Reddit post here to see if the people smarter than me can figure out what I'm doing wrong LOL.

bbrownchg commented 3 years ago

Found it in the logs, it seems like it doesn't like something with the tokens.

ERROR: Security token validation exception with requesting URL https://mycmg.example.com/CCM_Proxy_ServerAuth/72057594037927941/AdminService/wmi/SMS_Package?$filter=contains(Name,"Drivers"). System.IdentityModel.Tokens.SecurityTokenValidationException: There is no appropriate token validator to validate the token with issuer https://sts.windows.net/my-tenant-id/ and audience https://myapplicationiduri~~ at Microsoft.ConfigurationManager.CloudBase.AuthorizationToken.TokenValidator.ValidateJsonToken(String token)~~ at Microsoft.ConfigurationManager.CloudBase.AuthorizationToken.TokenValidator.ValidateTokenEx(String token, String tokenHint)~~ at Microsoft.ConfigurationManager.BgbServerChannel.BgbServerReverseProxy.ValidateAuthorizationToken(String authorizationToken, EndpointClientAuthScheme clientAuthScheme, Uri requestUri, IToken& validatedToken, EndpointClientAuthScheme& validatedScheme)

After doing some reading I noticed that this was generating a token against the v1 endpoint and not v2. To determine if this was the root cause, I updated the manifest on my app registrations to enable the v2 endpoint: "accessTokenAcceptedVersion": 2,

After doing that I'm able to generate a token on the v2 endpoint but still end up with the 401 unauthorized:

ERROR: Security token validation exception with requesting URL https://mycmg.example.com/CCM_Proxy_ServerAuth/72057594037927941/AdminService/wmi/SMS_Package?$filter=contains(Name,"Drivers"). System.IdentityModel.Tokens.SecurityTokenValidationException: There is no appropriate token validator to validate the token with issuer https://login.microsoftonline.com/my-tenant-id/v2.0 and audience my-app-registration-id~~ at Microsoft.ConfigurationManager.CloudBase.AuthorizationToken.TokenValidator.ValidateJsonToken(String token)~~ at Microsoft.ConfigurationManager.CloudBase.AuthorizationToken.TokenValidator.ValidateTokenEx(String token, String tokenHint)~~ at Microsoft.ConfigurationManager.BgbServerChannel.BgbServerReverseProxy.ValidateAuthorizationToken(String authorizationToken, EndpointClientAuthScheme clientAuthScheme, Uri requestUri, IToken& validatedToken, EndpointClientAuthScheme& validatedScheme) CMGService 6/9/2021 1:04:15 PM 31 (0x001F)

At this point I'm not sure if I'm going down the wrong rabbit hole or if I'm on to something 🤣.

bbrownchg commented 3 years ago

Just in case anyone else ran in to the problem I did, here's how I fixed it:

I noticed some inconsistencies from when I set up the CMG, I had a couple of different server apps configured in Azure. I was trying to reconfigure them and wasn't able to sign in to Azure via the console and came across this article: https://systemcenterdudes.com/failed-to-sign-in-to-azure-error-when-configuring-sccm-cloud-management-gateway/ Pretty much, I blew away my Azure services and tenant in my console and reconnected and created new server/client apps. Everything is working now!

MarkusMory commented 3 years ago

Cool that you got it working. But are you using a client secret or the basic authentication with username/password?

bbrownchg commented 3 years ago

Cool that you got it working. But are you using a client secret or the basic authentication with username/password?

Client secret won't work to auth against the AdminService as it requires ConfigMgr RBAC on the backend for all authentication. Until ConfigMgr is updated to understand something more than AD auth that'll remain the case. I'd have to imagine that MS has something in the works for this as they very much preach using service principals instead of traditional username/password authentication where possible.

I'm still using the default script which provides the MDM variables to set the credentials. Looking at the sign-in logs for the service account shows the client app as "Mobile Apps and Desktop clients" as it's using the ADAL library to generate the token.

Now, to go on what @gregor79 was saying earlier, my service account does redirect to my ADFS instance for authentication where we do still allow username/password authentication. I'm not sure how to workaround that piece without modifying the ADFS config. An alternative would be to set up a service account using a different domain name that uses managed authentication instead of federated. That would depend on the individual setup though.