Authentication using the Service Principal Authentication Method missing in version 3.5.4?

[KorZijl]

Hi, we are currently using version 3.1.16 with the Service Principal Authentication Method to authenticate to different tenants to retrieve the inventory. In the tenants we've created an Enterprise App with certificate authentication and we've set the appropriate read permissions on the resources. Every weekend we run a scheduled task that calls AzureResourceInventory.ps1 with the parameters TenantID, AppId and Secret for all those tenants.

Now we're trying to move from version 3.1.16 to version 3.5.4 but after testing it seems the Service Principal Authentication Method is not available anymore. Executing Invoke-ARI with those parameters returns a lot of "Run Connect-AzAccount to login" messages and the parameters AppId and Secret aren't mentioned anymore in the updated README (https://github.com/microsoft/ARI/tree/main?tab=readme-ov-file#3-parameters).

Did we miss a breaking change alert on this authentication method? And are you willing and planning to reimplement this method?

[Claudio-Merola]

Hi @KorZijl

Our idea was to initially remove the SPN support in the module version, that is why we removed from the README.

But some people have requested that functionality back and it should be working in the version 3.5.4

The parameters should be the same actually, -Appid and -Secret (the secret must be passed as plaintext).

If you are using the parameters correctly and still having issues, please send me the output of the script with the -Debug

[KorZijl]

Hi Claudio, We're using certificate authentication so we pass the PEM-file as the secret value instead of a plaintext secret successfully using version 3.1.16.

I've executed the command below and attached the result as picture (cause the debugging output is messing up the layout):

Invoke-ARI -TenantId 419a6976-xxxx-xxxx-xxxx-xxxxxxxxxxxx -AppId 1af2daf0-xxx-xxxx-xxxx-xxxxxxxxxxxx -Secret D:\ARI\AzureResourceInventory-BASE64-ALL.pem -ReportDir D:\ARI\Exports\TESTWORKZ -ReportName ARI_TESTWORKZ -Debug

I've also tested with Powershell 7.4.5 but the error output is almost similar.

[Claudio-Merola]

Hello @KorZijl

In the older versions we were using the az cli, since we moved to 100% Powershell we are using different methods, I don't think this will work the same way, for the current version we are using the following method to do the SPN authentication:

https://learn.microsoft.com/en-us/powershell/module/az.accounts/connect-azaccount?view=azps-12.3.0#example-3-connect-to-azure-using-a-service-principal-account

I believe we will need to build a new parameter for certificate file authentication.

[KorZijl]

Hi Claudio,

There are examples to use certificates but they rely on the Windows certificate store (example 7) or on PFX-files (example 9): https://learn.microsoft.com/en-us/powershell/module/az.accounts/connect-azaccount?view=azps-12.3.0#example-7-connect-using-certificates https://learn.microsoft.com/en-us/powershell/module/az.accounts/connect-azaccount?view=azps-12.3.0#example-9-connect-using-certificate-file

I need to rethink my authentication method i guess ;)

BTW: For testing purposes i've added a client secret to the enterprise app and used that as plaintext secret but i'm still getting "Run Connect-AzAccount to login" messages.

Invoke-ARI -TenantId 419a6976-xxxx-xxxx-xxxx-xxxxxxxxxxxx -AppId 1af2daf0-xxx-xxxx-xxxx-xxxxxxxxxxxx -Secret "x-M8Q~xxxxxxx~xxxx~xx~xxxxxxxxxxxxxxxxxx" -ReportDir D:\ARI\Exports\TESTWORKZ -ReportName ARI_TESTWORKZ -Debug

[TheOlek]

Hello @Claudio-Merola, im having the same issue as i try to login with Service Principal and i cant connect

[Claudio-Merola]

Hi @TheOlek

Are you also using a certificate to authenticate?

[TheOlek]

Hi @Claudio-Merola Im just using
Invoke-ARI -TenantId "" -AppId "" -Secret ""

[Claudio-Merola]

@TheOlek

Are you passing the secret as plaintext or securestring?

It has to be plaintext

[TheOlek]

@Claudio-Merola im passing as plain text is reader at subscription level enough?

[Claudio-Merola]

@TheOlek

Yes it is, can you run the command adding the -Debug and post the output here?

[TheOlek]

@Claudio-Merola

[Claudio-Merola]

@TheOlek

I think there was a bug there.

Can you try the version 3.5.6 and see if it works?

[TheOlek]

@Claudio-Merola im getting the same behaviour even with the new version

[Claudio-Merola]

@TheOlek

with the version 3.5.5 or 3.5.6?

I released version 3.5.5 and then found that bug, then I just released version 3.5.6 a few minutes after 3.5.5

[TheOlek]

@Claudio-Merola im using 3.5.6

[KorZijl]

I tested this again with 3.5.6 and encountered the same behavior as TheOlek.

[Claudio-Merola]

@TheOlek @KorZijl

I updated the module to the version 3.5.7

Can you guys try it using the -Debug parameter?

This version should at least give more details on what is going on during the authentication phase

[TheOlek]

@Claudio-Merola here it is