Bug: AADRoleEligibilityScheduleRequest fails on subsequent runs

[techthoughts2]

Description of the issue

The AADRoleEligibilityScheduleRequest is working without issue for deploying a permanent eligible assignment on the first run of Start-DSCConfiguration.

We have confirmed that the eligible assingment is in place, and working as intended.

However, subsequent runs of the DSC result fail with the overall error: The Role assignment already exists.

This seems to be related to the subsequent runs thinking that Ensure=Absent for some reason.

As a result, it tries to recreate the Role Eligibility request, but fails because it is already present.

Microsoft 365 DSC Version

v1.23.1011.1

Which workloads are affected

Azure Active Directory

The DSC configuration

AADRoleEligibilityScheduleRequest 'EligibilityGroupAssignment' {
    DependsOn             = @(
        '[AADRoleSetting]3a2c62db-5318-420d-8d74-23affee5d9d5'
        '[AADGroup]groupName'
    )
    Principal             = 'groupName'
    RoleDefinition        = 'Intune Administrator'
    PrincipalType         = 'Group'
    DirectoryScopeId      = "/";
    Action                = 'AdminAssign'
    Justification         = 'Assigning permanent eligibility for AEG team'
    IsValidationOnly      = $false
    ScheduleInfo          = MSFT_AADRoleEligibilityScheduleRequestSchedule {
        startDateTime = '2023-09-01T02:40:44Z'
        expiration    = MSFT_AADRoleEligibilityScheduleRequestScheduleExpiration {
            type = 'noExpiration'
        }
    }
    Ensure                = 'Present'
    ApplicationId         = $ApplicationId
    TenantId              = $TenantId
    CertificateThumbprint = $Thumbprint
}

Verbose logs showing the problem

2023-10-13T02:49:54.7966612Z [[AADRoleEligibilityScheduleRequest]EligibilityGroupAssignment::[AzureAD]AzureAD_Configuration] Current Values: 
2023-10-13T02:49:54.7972497Z Action=adminAssign
2023-10-13T02:49:54.7976154Z 
2023-10-13T02:49:54.7982126Z ApplicationId=***
2023-10-13T02:49:54.7985385Z 
2023-10-13T02:49:54.7991190Z CertificateThumbprint=***
2023-10-13T02:49:54.7994394Z 
2023-10-13T02:49:54.8000256Z DirectoryScopeId=/
2023-10-13T02:49:54.8004580Z 
2023-10-13T02:49:54.8010504Z Ensure=Absent
2023-10-13T02:49:54.8013787Z 
2023-10-13T02:49:54.8019807Z IsValidationOnly=False
2023-10-13T02:49:54.8023074Z 
2023-10-13T02:49:54.8029012Z Justification=Assigning permanent eligibility for AAA team
2023-10-13T02:49:54.8032191Z 
2023-10-13T02:49:54.8038260Z Principal=groupName
2023-10-13T02:49:54.8041287Z 
2023-10-13T02:49:54.8047095Z PrincipalType=Group
2023-10-13T02:49:54.8050184Z 
2023-10-13T02:49:54.8056218Z RoleDefinition=Intune Administrator
2023-10-13T02:49:54.8059392Z 
2023-10-13T02:49:54.8065277Z ScheduleInfo={expiration=MSFT_AADRoleEligibilityScheduleRequestScheduleExpiration; recurrence=; 
2023-10-13T02:49:54.8071679Z startDateTime=2023-09-01T02:40:44Z}
2023-10-13T02:49:54.8074660Z 
2023-10-13T02:49:54.8080638Z TenantId=***
2023-10-13T02:49:54.8083946Z 
2023-10-13T02:49:54.8090627Z Verbose=True
2023-10-13T02:49:54.8096754Z VERBOSE: [serverName]:                            
2023-10-13T02:49:54.8102710Z [[AADRoleEligibilityScheduleRequest]EligibilityGroupAssignment::[AzureAD]AzureAD_Configuration] Target Values: 
2023-10-13T02:49:54.8108536Z Action=adminAssign
2023-10-13T02:49:54.8111736Z 
2023-10-13T02:49:54.8117665Z ApplicationId=***
2023-10-13T02:49:54.8120925Z 
2023-10-13T02:49:54.8126918Z CertificateThumbprint=***
2023-10-13T02:49:54.8130101Z 
2023-10-13T02:49:54.8136090Z DirectoryScopeId=/
2023-10-13T02:49:54.8139315Z 
2023-10-13T02:49:54.8145279Z Ensure=Present
2023-10-13T02:49:54.8148471Z 
2023-10-13T02:49:54.8154367Z IsValidationOnly=False
2023-10-13T02:49:54.8157599Z 
2023-10-13T02:49:54.8164613Z Justification=Assigning permanent eligibility for AAA team
2023-10-13T02:49:54.8167751Z 
2023-10-13T02:49:54.8173791Z Principal=groupName
2023-10-13T02:49:54.8176979Z 
2023-10-13T02:49:54.8182979Z PrincipalType=Group
2023-10-13T02:49:54.8186147Z 
2023-10-13T02:49:54.8192106Z RoleDefinition=Intune Administrator
2023-10-13T02:49:54.8195927Z 
2023-10-13T02:49:54.8201935Z ScheduleInfo={expiration=MSFT_AADRoleEligibilityScheduleRequestScheduleExpiration; recurrence=; 
2023-10-13T02:49:54.8207969Z startDateTime=2023-09-01T02:40:44Z}
2023-10-13T02:49:54.8210949Z 
2023-10-13T02:49:54.8216960Z TenantId=***
2023-10-13T02:49:54.8220157Z 


2023-10-13T02:49:57.0697876Z Build FAILED. 1 tasks, 1 errors, 0 warnings 00:02:30.7616659
2023-10-13T02:49:57.2399816Z ##[error][RoleAssignmentExists] : The Role assignment already exists.
At C:\AzurePipeline-Agent\_work\1\s\BuildScripts\Set-DSCConfiguration.ps1:51 char:9
+         Start-DscConfiguration @startDscConfigurationSplat
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: ({ body = Micros...heduleRequest }:) [], CimException
    + FullyQualifiedErrorId : RoleAssignmentExists,Microsoft.Graph.Beta.PowerShell.Cmdlets.NewMgBetaRoleManagementDire 
   ctoryRoleEligibilityScheduleRequest_CreateExpanded
    + PSComputerName        : localhost
2023-10-13T02:49:57.2423619Z ##[error]PowerShell exited with code '1'.

### Environment Information + PowerShell Version

OsName               : Microsoft Windows Server 2022 Datacenter
OsOperatingSystemSKU : DatacenterServerEdition
OsArchitecture       : 64-bit
WindowsVersion       : 2009
WindowsBuildLabEx    : 20348.1.amd64fre.fe_release.210507-1500
OsLanguage           : en-US
OsMuiLanguages       : {en-US}

Name                           Value
----                           -----
PSVersion                      5.1.20348.1850
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.20348.1850
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

[NikCharlebois]

Are there any other error thrown in the verbose output? I am failing to repro with the shared config above.

[techthoughts2]

We are seeing this in the M365DSC log:

{ Cannot process argument transformation on parameter 'GroupId'. Cannot convert value to type System.String. } \ at Get-TargetResource, C:\Program Files\WindowsPowerShell\Modules\Microsoft365DSC\1.23.1011.1\DscResources\MSFT_AADRoleEligibilityScheduleRequest\MSFT_AADRoleEligibilityScheduleRequest.psm1: line 196
 \ at Set-TargetResource, C:\Program Files\WindowsPowerShell\Modules\Microsoft365DSC\1.23.1011.1\DscResources\MSFT_AADRoleEligibilityScheduleRequest\MSFT_AADRoleEligibilityScheduleRequest.psm1: line 403

This is only happening on 2 out of 30 of our MSFT_AADRoleEligibilityScheduleRequest configurations. But no matter what we try, two consistently fail. We have not yet determined what is different about these configurations vs others that leads to the issue.

[techthoughts2]

This is seen in the Microsoft-Windows-Desired State Configuration/Operational logs:

Job {C6556F91-7288-11EE-BA36-0AF65DFD1103} : 
This event indicates that a non-terminating error was thrown when DSCEngine was executing Set-TargetResource on MSFT_AADRoleEligibilityScheduleRequest DSC resource. FullyQualifiedErrorId is RoleAssignmentExists,Microsoft.Graph.Beta.PowerShell.Cmdlets.NewMgBetaRoleManagementDirectoryRoleEligibilityScheduleRequest_CreateExpanded. Error Message is [RoleAssignmentExists] : The Role assignment already exists..

[andikrueger]

It look like two of the instances returned by Get-MgBetaRoleManagementDirectoryRoleEligibilityScheduleRequest do not have a property PrincipalId or the ID is in a format, that cannot be converted to String.

Microsoft365DSC/Modules/Microsoft365DSC/DSCResources/MSFT_AADRoleEligibilityScheduleRequest/MSFT_AADRoleEligibilityScheduleRequest.psm1

Line 196 in a58b818

$PrincipalInstance = Get-MGGroup -GroupId $request.PrincipalId -ErrorAction SilentlyContinue

Is it possible, that there Roles with outdated groups? Could you that all settings do have current groups?

[NikCharlebois]

Good catch. I was able to reproduce as follow:

1 - Create a role eligibility assignment for a given group.

2 - Soft delete that group

3 - Run the DSC config to monitor the assignment.

@techthoughts2 is there a chance that the group assigned to the role eligibility has been deleted? Thanks

[techthoughts2]

I have verified that the group has not been deleted.
It is present and has active members.
The group is also configured via DSC, and is listed as a dependency for the Eligibility assignment:

DependsOn             = @(
    '[AADRoleSetting]3a2c62db-5318-420d-8d74-23affee5d9d5'
    '[AADGroup]groupName'
)

[NikCharlebois]

Re-opening as we are still seeing ad-hoc instances of this issue surface.

[gibi916]

I have the same problem but only when I specify a DirectoryScopeId different from the root "/". If I take the example of the original post and add a DirectoryScopeId on an administrative unit (DirectoryScopeId = "/administrativeUnits/5c8d1d0d-3ff7-415e-898f-b166f40f2462";), I can reproduce the bug every time.
So on the first run everything goes well, and on the 2nd run I get the error The Role assignment already exists.

AADRoleEligibilityScheduleRequest 'EligibilityGroupAssignment' {
    DependsOn             = @(
        '[AADRoleSetting]3a2c62db-5318-420d-8d74-23affee5d9d5'
        '[AADGroup]groupName'
    )
    Principal             = 'groupName'
    RoleDefinition        = 'Intune Administrator'
    PrincipalType         = 'Group'
    DirectoryScopeId      = "/administrativeUnits/5c8d1d0d-3ff7-415e-898f-b166f40f2462";
    Action                = 'AdminAssign'
    Justification         = 'Assigning permanent eligibility for AEG team'
    IsValidationOnly      = $false
    ScheduleInfo          = MSFT_AADRoleEligibilityScheduleRequestSchedule {
        startDateTime = '2023-09-01T02:40:44Z'
        expiration    = MSFT_AADRoleEligibilityScheduleRequestScheduleExpiration {
            type = 'noExpiration'
        }
    }
    Ensure                = 'Present'
    ApplicationId         = $ApplicationId
    TenantId              = $TenantId
    CertificateThumbprint = $Thumbprint
}

So I can say for sure that the bug is still present when using a scope on an administrative unit.
Thanks for your help !