starred/CIPP

Fork 0

mirror of https://github.com/KelvinTegelaar/CIPP.git synced 2026-04-25 08:16:01 +03:00

[GH-ISSUE #1643] Domain moved to other tenant is applying standards of both tenants. #885

New issue

Closed

opened 2026-03-02 12:46:02 +03:00 by kerem · 3 comments

kerem commented

2026-03-02 12:46:02 +03:00

Owner

Originally created by @mpowelltech on GitHub (Jul 24, 2023).
Original GitHub issue: https://github.com/KelvinTegelaar/CIPP/issues/1643

Description

Have a bit of a weird one here.

Background
We had 2 M365 tenants for a client and their subsidary, both in CIPP, let's call them contoso.com and contososub.com.

We initially setup contososub.com as a new tenant, setup GDAP and configured a bunch of very restrictive standards in CIPP.
Then we decided to put the contososub.com domain in the contoso.com tenancy and shut down the new separate tenancy.

However, the old contososub.com is still in CIPP as a separate tenant, but it seems to reference the contoso.com tenant.
So in CIPP, going to contoso.com > Users, we see all the contoso.com users and all the contososub.com users as well (expected). But if in CIPP we go to contososub.com > Users, it lists the same users.

The bigger issue is that all the restrictive standards policies we setup for the new contososub.com domain in their new tenant have now started applying to the existing contoso.com tenant, despite only being applied to the (now non-exisitent) contososub.com tenant in CIPP.

I imagine this is related to scripts that are all referencing the domain name (and not something like the tenant ID instead), so when we moved the domain name to the new tenant, the standards started applying there instead.

Suspect it's a pretty rare issue, and at this point our fix is simply removing all stadards applied to contososub.com, and we'll figure out how to best remove the tenant from CIPP, but just thought I'd raise it as an issue, in case there is a better way to reference the tenant ID (which will stay with a tenant) instead of domain names (which are very occasionally moved to a different tenant).

Steps to reproduce:

Create a new tenant (TenantB) with default domain of contososub.com and add it to GDAP/CIPP
Create standards for TenantB (contososub.com) in CIPP
Remove contososub.com domain from TenantB tenant and add it to existing TenantA tenant.
Now any standards that are applied to TenantB will apply to TenantA instead.

Love your work!

Environment data

Sponsored / Non-sponsored instance: Non-sponsored
Front end version number: 3.8.0
Back end version number: 3.8.1
Tried Tenant Cache Clear: true
Tried Token Cache Clear: false

Originally created by @mpowelltech on GitHub (Jul 24, 2023). Original GitHub issue: https://github.com/KelvinTegelaar/CIPP/issues/1643 ### Description Have a bit of a weird one here. **Background** We had 2 M365 tenants for a client and their subsidary, both in CIPP, let's call them contoso.com and contososub.com. We initially setup contososub.com as a new tenant, setup GDAP and configured a bunch of very restrictive standards in CIPP. Then we decided to put the contososub.com domain in the contoso.com tenancy and shut down the new separate tenancy. However, the old contososub.com is still in CIPP as a separate tenant, but it seems to reference the contoso.com tenant. So in CIPP, going to contoso.com > Users, we see all the contoso.com users and all the contososub.com users as well (expected). But if in CIPP we go to contososub.com > Users, it lists the same users. The bigger issue is that all the restrictive standards policies we setup for the new contososub.com domain in their new tenant have now started applying to the existing contoso.com tenant, despite only being applied to the (now non-exisitent) contososub.com tenant in CIPP. I imagine this is related to scripts that are all referencing the domain name (and not something like the tenant ID instead), so when we moved the domain name to the new tenant, the standards started applying there instead. Suspect it's a pretty rare issue, and at this point our fix is simply removing all stadards applied to contososub.com, and we'll figure out how to best remove the tenant from CIPP, but just thought I'd raise it as an issue, in case there is a better way to reference the tenant ID (which will stay with a tenant) instead of domain names (which are very occasionally moved to a different tenant). **Steps to reproduce:** 1. Create a new tenant (TenantB) with default domain of contososub.com and add it to GDAP/CIPP 2. Create standards for TenantB (contososub.com) in CIPP 3. Remove contososub.com domain from TenantB tenant and add it to existing TenantA tenant. 4. Now any standards that are applied to TenantB will apply to TenantA instead. Love your work! ### Environment data ```PowerShell Sponsored / Non-sponsored instance: Non-sponsored Front end version number: 3.8.0 Back end version number: 3.8.1 Tried Tenant Cache Clear: true Tried Token Cache Clear: false ```

kerem

2026-03-02 12:46:02 +03:00

closed this issue
added the
bug

unconfirmed-by-user
labels

kerem commented

2026-03-02 12:46:03 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Jul 24, 2023):

Thank you for creating a bug. Please make sure your bug is indeed a unique case by checking current and past issues, and reading the complete documentation at https://docs.cipp.app/
If your bug is a known documentation issue, it will be closed without notice by a contributor. To confirm that this is not a bug found in the documentation, please copy and paste the following comment: "I confirm that I have checked the documentation thoroughly and believe this to be an actual bug.".

Without confirming, your report will be closed in 24 hours. If you'd like this bug to be assigned to you, please comment "I would like to work on this please!".

@github-actions[bot] commented on GitHub (Jul 24, 2023): Thank you for creating a bug. Please make sure your bug is indeed a unique case by checking current and past issues, and reading the complete documentation at https://docs.cipp.app/ If your bug is a known documentation issue, it will be closed without notice by a contributor. To confirm that this is not a bug found in the documentation, please copy and paste the following comment: "I confirm that I have checked the documentation thoroughly and believe this to be an actual bug.". Without confirming, your report will be closed in 24 hours. If you'd like this bug to be assigned to you, please comment "I would like to work on this please!".

kerem commented

2026-03-02 12:46:03 +03:00

Author

Owner

@mpowelltech commented on GitHub (Jul 24, 2023):

I confirm that I have checked the documentation thoroughly and believe this to be an actual bug.

@mpowelltech commented on GitHub (Jul 24, 2023): I confirm that I have checked the documentation thoroughly and believe this to be an actual bug.

kerem commented

2026-03-02 12:46:03 +03:00

Author

Owner

@KelvinTegelaar commented on GitHub (Jul 24, 2023):

currently not accepting bug reports/feature requests by non-sponsors due to CIPP workload. Feel free to sponsor and request a reopen.

@KelvinTegelaar commented on GitHub (Jul 24, 2023): currently not accepting bug reports/feature requests by non-sponsors due to CIPP workload. Feel free to sponsor and request a reopen.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/CIPP#885

No description provided.

Rows
Columns