"Deploying ALZ" assumes user is local to tenant

[kennethmac2000]

Describe the bug
"Deploying ALZ" assumes that the user deploying ALZ is local to the tenant.

This could be solved by replacing az login with az login --tenant <tenant_id>.

Note that for scope '/' (in the next command) to be correctly resolved, you need to have access to at least one subscription on the tenant you are logging in to, so that this subscription can be set as the default subscription. If you have created a brand new tenant to deploy ALZ to, it may not have any subscriptions. This point should also be called out.

[jtracey93]

Hey @kennethmac2000

Thanks for the issue. Would you be up for submitting a PR to the doc to change/update this https://github.com/Azure/Enterprise-Scale/blob/main/docs/wiki/Deploying-ALZ.md ?

Let us know

[kennethmac2000]

Hi,

Probably not to be honest, as it would require further research to identify the exact nature of the problem - eg, do you need to have access to at least one subscription even if you are logging in to a tenant with a local user, or does this only apply if you are logging in to a different tenant?

It would then also need research and testing of the appropriate PowerShell commands, with which I am not so familiar.

This all takes time.

That said, if there is a way of splitting up the work required, I would be happy to contribute. :) I just don't have time to do it from start to finish.

[Springstone]

@kennethmac2000 I'm not sure if I understand. You obviously cannot deploy the Azure Landing Zone, without having access to subscriptions (minimum 3 - best practice). These permissions need to be in place prior to starting the provisioning process.

What you're referring to is a user that have access to multiple tenants with the same login credentials. Users in that situation should know how to switch tenants when logging in.

[kennethmac2000]

Hi @Springstone,

Thanks for your thoughts. Let me address each of your points in turn.

1. As I mentioned in my original comment, “If you have created a brand new tenant to deploy ALZ to, it may not have any subscriptions.” (This is exactly what I did BTW.)

   As a counter to that, you say (a) that one “obviously” cannot deploy ALZ without having access to subscriptions, and (b) that “these permissions” (presumably permissions to the aforementioned subscriptions) need to be in place prior to starting the provisioning process.

   How is this so obvious? Where on the page are points (a) and (b) documented? Not in the prerequisites as far as I can see, and only obliquely on the page at all.

   It’s also not clear to me that the simple act of logging in to a particular tenant is part of the provisioning process proper.

2. You say that users in the situation of having access to multiple tenants with the same login credentials “should” know how to switch tenants when logging in.

   Why “should” they?

   I have access to many tenants with the same login credentials, yet I normally interact with all of those tenants through Azure Portal. I had to spend time working out conceptually what I needed to do and then researching how to do it with Azure CLI. Why not solve this once for all users rather than requiring multiple people to waste time solving it for themselves?

That all said, I am happy to put my money where my mouth is and help update the page - if we are agreed that we should make the changes I have proposed, and we aren’t going to debate this again after I spend time crafting a PR.

[Springstone]

Hi @kennethmac2000, welcome your contribution with updates to documentation to clarify the topics you've outlined.

[kennethmac2000]

Before I do, does someone know the answer to this question...?

Do you need to have access to at least one subscription even if you are logging in to a tenant with a local user, or does this only apply if you are logging in to a different tenant?

Please don't repeat the point that you "obviously" cannot deploy ALZ without having access to subscriptions. This is about the order in which one does things. If you've just created a brand new tenant to deploy ALZ to, you might not have created any subscriptions yet. Indeed, the documentation doesn't explicitly tell you to create subscriptions at any point. (In fact, you might reasonably assume that the ALZ code will create the required subscriptions on your behalf - why would that "obviously" not be the case?)

[Springstone]

Hi @kennethmac2000. For an Azure Landing Zone deployment, you need to provide subscriptions IDs for the functional areas of ALZ as it deploys management, identity, connectivity and optionally landing zones like corp/online resources into those subscriptions. ALZ does not create subscriptions for you, and you need to provide those subscription IDs as part of the initial deployment configuration.

Once ALZ is deployed and configured, you can look at "Subscription Vending" to provision subscriptions for workloads. You can read more on this here: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/subscription-vending

To clarify for ALZ:

• Create new tenant
• Provision subscriptions (3 for platform, and as many as needed for corp/online workloads)
• Follow pre-requisite guidance prior to deploying ALZ here: https://github.com/Azure/Enterprise-Scale/wiki/Deploying-ALZ-Pre-requisites
• You should now be able to deploy Azure Landing Zones providing subscription IDs for connectivity, identity and management areas of ALZ (using the created subscriptions - which you can rename for easier reference).

[kennethmac2000]

Thanks for your comments @Springstone. However, they don’t appear to answer my question, which, for ease of reference, was:

Do you need to have access to at least one subscription even if you are logging in to a tenant with a local user, or does this only apply if you are logging in to a different tenant?

For the avoidance of doubt, this question is nothing to do with ALZ, and simply relates to the mechanics of logging in to a tenant.

On a separate note, your comments about the need for subscriptions are useful. I think it would be helpful to make this point much more explicit in the documentation.

[Springstone]

Hi @kennethmac2000. I'm a little unclear on what you are trying to achieve and the multiple tenant scenario you are describing.

To clarify, as long as your account is an Owner (regardless of tenant) in the tenant you want to deploy Azure Landing Zone INTO, AND subscriptions are available under the tenant in question, and you've followed the pre-requisites (to do this you will also need to be an Entra ID tenant "Global Administrator" - at least to grant your account tenant Owner permissions), you should be good.

For reference, this is the key:

Follow pre-requisite guidance prior to deploying ALZ here: https://github.com/Azure/Enterprise-Scale/wiki/Deploying-ALZ-Pre-requisites.

If you are logging into another tenant using your credentials, your home tenant (the account you are logging in with) DOES NOT need a subscription available. You only need subscriptions in the target environment where ALZ will be deployed, as described above.

[Springstone]

I do want to clarify that it is not recommended to grant owner permissions to guest accounts (accounts outside the tenant in question), and it is a recommended practice to rather create a dedicated user in the tenant where you want to deploy ALZ. This reduces attack surface and possible security gaps due to account compromise.

[kennethmac2000]

@Springstone My question remains as it was, and, again, has nothing to do with ALZ per se.

If I log in to a different tenant to the one providing my identity, I need to have access to at least one subscription on that tenant or else scope '/' will not be correctly resolved. Is that also the case if you are logging in to the tenant which is providing your identity?

This is important and relevant because it is possible and perhaps even likely that you will have created a brand new tenant to deploy ALZ to, and may be running the commands in ‘Grant Access to the User at tenant root scope “/” to deploy Azure landing zone accelerator‘ before creating any subscriptions on the tenant.

[jtracey93]

Hey, just adding my $0.02 here.

This repo is for ALZ, hence @Springstone providing guidance in the context of this.

However to your question outstanding @kennethmac2000, you do not need a subscription in a tenant to log into it via CLI/PWSH etc. for CLI you can use the command az login --tenant '<Tenant ID>' --allow-no-subscriptions and the same is supported in the AZ PowerShell and you can see a thread on it here: Azure/azure-powershell#21161

Hope that helps settle this discussion and we can now get the docs update, hopefully via a PR from yourself @kennethmac2000, to help clarify this from your perspective to help others as you are seeing it from another useful angle to myself and @Springstone 👍

Thanks in advance for helping clarify for everyone

[kennethmac2000]

Thanks @jtracey93, but that is also not the question.

If I create a brand new tenant to deploy ALZ onto (so far, no-one has argued that this isn't a likely scenario), it will contain no subscriptions.

If I then diligently follow the instructions in 'Deploying ALZ', I will come to 'Grant Access to the User at tenant root scope “/” to deploy Azure landing zone accelerator' before the point at which I am told to create any subscriptions. (Which is exactly what I did - with the exception that I used az login --tenant <tenant_id> instead of az login)

In my case, where my new tenant was not the one providing my identity, the command "az role assignment create --scope '/' --role 'Owner' --assignee-object-id $(az ad signed-in-user show --query id --output tsv)" failed, as it seems that at least one subscription (to which one has access) is required for '/' to be correctly resolved.

My question is: is that also the case if you are logging in to a tenant with a local user identity? Or will '/' resolve correctly in this case, even in the absence of access to any subscriptions?

PS @Springstone may say that "obviously" subscriptions are required, but up until this point in the document subscriptions are not mentioned at all (and even after this point, they are only mentioned obliquely). I think this could probably be improved (because I don't think it's obvious that subscriptions are required - the ALZ template could plausibly create subscriptions on your behalf), but it wasn't my intention to do so as part of this enhancement, as that is a bigger change. Hence, we need to handle the situation as it stands where a user gets to 'Grant Access to the User at tenant root scope “/” to deploy Azure landing zone accelerator' without having been told to do anything specific with regards subscriptions.

[jtracey93]

Hey @kennethmac2000,

You should ideally try and use this command when logging in to advise the client there are no subs az login ....... --allow-no-subscriptions

However, you will also need to Elevate your account on the tenant to have access to the / scope as default permissions, even creating it are not enough: https://learn.microsoft.com/en-us/azure/role-based-access-control/elevate-access-global-admin?tabs=azure-portal

Then after elevating you should be able to grant the RBAC at the / scope

If you only want to create the management groups and policy definitions then you do not need subs at that stage, but prior to making assignments you will need subs as the deploy if not exists policies need some resources like log analytics workspace etc.

Thanks

[kennethmac2000]

Hi @jtracey93,

Elevating my account to manage access to all Azure subscriptions and management groups is documented in "Deploying ALZ", was something I did, and is not what we are discussing here as far as I'm aware.

I'm not really sure why, but we seem to keep drifting off the very narrow topic at hand.

When I deployed ALZ, this is what I did:

1. Created a brand new tenant using an identity from another tenant.
2. Logged in to the new tenant in Azure Portal using that same identity from another tenant and elevated my access.
3. Authed to the new tenant using the Azure CLI, again using that same identity from another tenant, by running az login --tenant <tenant_id>
4. Tried running az role assignment create --scope '/' --role 'Owner' --assignee-object-id $(az ad signed-in-user show --query id --output tsv), which failed without my having access to any subscriptions on the tenant, as scope '/' could not be resolved.

My question remains... if I had instead created a new local user on the new tenant and authed to the tenant with that user in point 3, would the command in point 4 have worked, even in the absence of any subscriptions?

I could test this myself, but that would require spining up another test tenant and I was hoping we could share the work here/I assumed someone might already know the answer.

(If we can, please let's focus on this very narrow point until we've bottomed it out.)

[jtracey93]

As long as you add the ... --allow-no-subscriptions to the login command @kennethmac2000. Yes this should work.

[kennethmac2000]

I was looking to start making updates to this page, but then noticed that it hasn’t been updated for a year, and there are other flavours of “Deploying ALZ”, each of which seems to be slightly out of sync with the others (eg, Deploying-ALZ-BasicSetup.md).

Is it still worth updating this page, or are people being redirected to other pages now and this page is deprecated? (An honest answer would be appreciated - I don’t want to spend time updating a page just for tidiness’ sake if it’s no longer being actively maintained. 😊)

For the historical record in any case, these are the things that I think need fixed with this page:

1. The “Prerequisites” section should explain what subscriptions require to be created, and what the options are here. (I note that, eg, Deploying-ALZ-BasicSetup.md does include this information.)
2. The az login command should be updated to include --allow-no-subscriptions. (This is not required in all cases, but it keeps things cleaner to just include it in all cases rather than defining multiple sub-scenarios.)
3. The PowerShell equivalent of point 2.
4. The section with the az login command should be updated to also include the option of logging in to a different tenant to the one providing your identity (a not uncommon scenario) - ie, with az login --tenant. (As mentioned previously, people may be familiar with doing this in Azure Portal, but won’t necessarily be aware it needs an extra argument at the command line.)
5. The PowerShell equivalent of point 4.