uniqueName for Users

[slavizh]

Is your feature request related to a problem? Please describe.
Users can be members of groups. Due to that would be good if you can add them to groups using existing syntax. Currently that is not possible due to users not being part of the resources available in Bicep Graph.

Describe the solution you'd like
With this I would like not specifically to be able to deploy users with Bicep Graph but to at least being able to reference them by unique name. As uniqueName is something that can be updated by Graph API and it is something that most Graph resources in Bicep have would makes things easier if you can use existing syntax for users before being able to deploy the users via Bicep. I would assume just adding uniqueName to user resources it will be a lot easier than just making it available for creation via Bicep.

Additional context
Add any other context or screenshots about the feature request here.

[dkershaw10]

@eketo-msft we should take a look at this. This makes sense to me. I wonder if we should do the same for devices, while we are at it. @slavizh already has a legitimate ask for adding uniqueName property to groups too - #128

[slavizh]

Additionally to add scenario to this - there are many Azure resources that allow configuring (via Bicep) Microsoft Entra users, groups or service principals for authenticating to the service's data plane.

[eketo-msft]

@slavizh, would userPrincipalName work for your scenarios? It's not an alternate key (officially) and it can change, but it is unique and there is reluctance to add additional "name" properties to the User resource.

[slavizh]

@eketo-msft yes it should be sufficient.

[eketo-msft]

Quick update: We added support for UPN as an alternative key on the User resource in MS Graph. Next up we're working on Bicep type support so it can be used with the existing keyword. That is likely to land in early December due to lockdowns for the US elections and Thanksgiving holidays.

[slavizh]

@eketo-msft awesome! that will make referencing users even more easier.

[alex-frankel]

@eketo-msft - does that mean something like this will work?

resource user 'Microsoft.Graph/users@v1.0' existing = {
  userPrincipalName: 'alfran@microsoft.com'
}

output objectId string = user.objectId

If so, then I think it will also close this issue:
Azure/bicep#645

[eketo-msft]

@alex-frankel, exactly. It will allow reading an existing user by UPN and then referencing the user for operations, like managing membership, which require objectId (or id in MS Graph).

[alex-frankel]

Amazing! You will make a lot of people happy with this one!

[Gijsreyn]

I don't know if this feature was already implemented, but I would like the ability to fetch it in reverse, so in this case:

resource user 'Microsoft.Graph/users@v1.0' existing = {
  objectId: deployer().objectId
}

output upn string = user.userprincipalName

This allows me to use it in the api-management module as such:

module apiManagement 'br/public:avm/res/api-management/service:0.6.0' = {
    name: 'apiManagement'
    params: {
        name: 'apim${resourceGroup().name}'
        publisherEmail: upn
        publisherName: upn
        sku: 'Basic'
        managedIdentities: {systemAssigned: true}
    }
}

[dkershaw10]

@Gijsreyn The new (read-only) users Bicep type should be available later this month.
It won't feature the reverse-lookup as far as I know (as the main requirement here was to expose a unique friendly name for users which has a better experience in declarative config-as-code files).

Maybe a better bet would be to have the deployer() function also return UPN? We'll also look into whether we can do a reverse lookup.

Another thing to note, is that while the email address is often set to the same value as UPN, that is not always the case, so you might be setting the publisherEmail incorrectly. Better to use the user's mail property.

[Gijsreyn]

Hey @dkershaw10. You are right, I want the email property in the above use case. It would be pretty cool to see this functionality being added to Bicep in someway. Thanks for the quick response.

[dkershaw10]

Once this feature ships, you'll be able to look up a user by UPN and get various key properties for the user, including their mail address. You can what the users Bicep type will look like here: https://github.com/microsoftgraph/msgraph-bicep-types/blob/main/generated/microsoftgraph/microsoft.graph/v1.0/0.1.9-preview/types.md#resource-microsoftgraphusersv10-readonly

@alex-frankel would you be open to updating the deployer() function to return UPN as well?

[Gijsreyn]

Thanks Dan, looking forward to it.

[alex-frankel]

Tagging @levimatheri who implemented the deployer() function. If memory serves, it was not cheap to return UPN, which is why it got scoped out, but let's see.

[eketo-msft]

This is working as of Bicep v0.33.

extension 'br:mcr.microsoft.com/bicep/extensions/microsoftgraph/v1.0:0.1.9-preview' as graph

resource user 'Microsoft.Graph/users@v1.0' existing = {
userPrincipalName: 'person@contoso.com'
}

output id string = user.id

[levimatheri]

Tagging @levimatheri who implemented the deployer() function. If memory serves, it was not cheap to return UPN, which is why it got scoped out, but let's see.

Update: We revisited this, and found out we should be able to add userPrincipalName to the deployer() function cheaply.

[dkershaw10]

This is working as of Bicep v0.33.

extension 'br:mcr.microsoft.com/bicep/extensions/microsoftgraph/v1.0:0.1.9-preview' as graph

resource user 'Microsoft.Graph/users@v1.0' existing = { userPrincipalName: 'person@contoso.com' }

output id string = user.id

Sample demonstrating this is here: https://github.com/microsoftgraph/msgraph-bicep-types/tree/main/quickstart-templates/security-group-add-user-members

NOTE that it requires use of dynamic types and the 0.1.9 Graph Bicep types release.