Questions[security-groups](server)

We installed a new Exchange 2016 server and migrated all the mailboxes from the Exchange 2010 server to it. Then we migrated all the mailboxes and public folders from MSEX2016 to Office 365, and we demoted and shut down the MSEX2010. The local AD gets synchronized with Azure AD by the Azure AD Connector on one of our local servers.

This worked for a couple of weeks without problems. All the clients were able to access the public folders and their mailboxes on O365.

Yesterday we demoted the MSEX2016, which had already been turned off for testing a couple of days before. There was no PF active on it, but it was not possible to remove the databases in the regular way, since it always showed that the server is still in migration mode. It did not help to manually set attributes (like MigrationComplete...) and we finally removed them with the force option, demoted the server and shut it down.

After that, on the clients the message appeared that the Exchange Administrator performed changes which required a restart of the Outlook client. Not sure why this message showed up, since alle the clients were already connected to the O365 and there should not have been any established connection to the old MSEX2016.

Yesterday, I also changed the Azure AD Connector that it synchronizes just some of the needed OUs.

Today the issue appeared that no one was able to access the PF anymore. I found then out, that the SID on the folder permissions of the assigned groups are shown as unknown.

The user SIDs look fine, the problem is only on the groups. I thought first this has maybe something to do with the OU limitation of the Azure AD Connector and I re-activated the full sync how it was before, but it did not help.

I am also not able to change any permissions via the WebGUI, it ends up with the following message.

`System throws an exception at calculating Lambda Expression : [ Boolean(@0[ApplyToSubFolders]) ] Exception has been thrown by the target of an invocation. ERROR

System throws an exception at calculating Lambda Expression : [ Boolean(@0[ApplyToSubFolders]) ] Exception has been thrown by the target of an invocation.`

I was able to create a new "test" folder in the root PF, but I am not able to setup any permissions there via the WebGUI.

It is possible to change permissions via an Outlook client. If I remove there one of the group permissions and re-add it, then the SID is shown and everything works fine. Means to me all the groups are known in general at O365 (they are also shown there in the Exchange Admin WebGUI), but on the existing permissions they are not assigned to it.

Why is it not possible to set a PF permission via the WebGUI?

Why did it lose its assignment from the existing public folder group permissions to the SIDs and how to fix it without to remove and re-add all permissions manually?

Edit 1 (Monday 2021-10-18):

In the meanwhile the group permissions completely disappeared.

Edit 2 (Thursday 2021-10-21):

There is a Microsoft ticket open since Monday, but they cannot explain why the permissions disappeared and their software engineers are working on it to figure out what happened. They are also investigating why it is not possible to set the permissions via the WebGUI. Their proposed solution was to set all the permissions by hand on all the folders with Outlook or with PowerShell, what did not satisfy me since we have about 2700 folders. They were not willing ("building custom scripts is generally outside of our support boundaries") to provide a script to re-apply the permissions from the XML file which was created during the migration and they did not show up with any other solution to get the permissions back.

I was in the meanwhile able to re-apply the public folder permissions with this script created by myself and by the support of the community.

Edit 3 (Saturday, 2021-10-30)

MS says, that the problem with the WebGUI permission settings is well known: "the reported issue is caused by a known problem (which is being addressed by our Product Engineering team from the backend)" They recommend to use Outlook clients or the PowerShell to change permissions on the public folders.

They further say that I cannot prove that the permission got not deleted by an admin activity, since our audit log was not enabled (per MS default) and I cannot show recordings about it. I have sent again my screenshot to them which shows the strange situation with the missing SID on the group permissions to point out that this is a problem in the MS infrastructure. I am the only guy who has admin access and I am sure that I did not delete permissions on the public folders.

Edit 4 (Sunday, 2021-11-14)

Answer from MS: "Regarding the issue with assigning permissions through the admin center UI, my colleague advised that this problem is already published externally, as the issue is know for some time now. As previously mentioned, our Product Engineering team is currently working on developing a permanent fix, however, there is no specific ETA at the moment so we cannot fully confirm when to expect the resolution. For more information, you can also refer to the Public folder permissions and settings don't propagate in EAC article (it also includes the PowerShell script we suggested, which is the official workaround for this problem that our colleagues have provided)."

"From the information you have shared with us so far (including the screenshot from the EAC, which shows the missing SIDs), my colleague suspects that the affected public folders were migrated normally to Exchange Online, however, the Mail-security groups granting permissions to users were not synchronized afterwards (or there was an issue with the synchronization process). As a result of that, these permission groups were considered orphaned/stale and have been deleted with our consistency agent, which runs every 7 days in the backend." "Having said that, this behaviour is by design, but we sadly cannot fully confirm why the permissions were detected as stale in the first place. For more information about this matter, we recommend to review the official Announcing the Public Folder Consistency Agent for Exchange Online post from the Exchange development team, which explains how the agent works."

Situation

We have a web app hosted on Amazon EC2. It's intended to be used only by a few users in a company.

How we're dealing with this

• We share the (Elastic) IP address of the instance with the users.
• We add each user's IP address to the security group of the instance as and when needed.

When I say as and when needed, I mean emails from the users complaining that the web portal is showing an error page. They forget that this step of including the IP in the security group is required (and I don't blame them; they're end users).

For the sake of this question, let's assume we have a total of 5 users in a company who need this access. IP addresses of User-1 and User-2 have already been added to the security group.

Problems

1. User-3 goes to the IP address directly, but isn't able to access it as the user's IP address hasn't been added to the security group.
2. If User-1 or User-2 restart their internet, their IP address will likely change (dynamic IP provided by ISP) and the new IP address will have to be added to the security group (and the old one will have to be revoked to avoid access by others).

Other options I'm considering

1. Provide access only to their office VPN and ask all users to connect through it.
2. (Very cumbersome for the user) Ask the users to log in to the AWS management console, go to EC2 service, go to Security Groups section and add their IP addresses manually (the users already have AWS IAM users and appropriate permissions to perform this).
3. Create a script that adds the user's current IP to the security group (using AWS CLI / SDK) - sounds very dangerous and inappropriate as we'll have to include someone's API credentials in the script.

Overview

We have been working on getting our numerous sites to map share drives for each user that needs access to their sites. We have no way of standardizing this from within their AD profile as some users move around a lot and end up not telling IT until they need access to a particular site share drive. In turn we have created security groups for each site and will be using this as an item-level target within a Group Policy at the root of our AD structure for the sites, hoping it will trickle down and give only those in the security groups the drives they need.

System Information

Operating System: Windows Server 2016

The following relates to four machines across two DCs

Domain Controllers (GPO, Active Directory)

Operating System: NetApp which will be replaced in the near future with Nutanix Files.

Share Drives for each of our sites under the root and no sub-share's as the users will be populating these shared folders with whatever files they use/create

Structure

We map a drive to our users that connects to our NetApp appliance. The NetApp appliance has subfolders based on each site name, which in turn have whatever the users put in these folders. The structure looks similar to the following:

NetApp Shares
├── Site 1
├── Site 2
├── Site 3
├── Site 4
├── Site 5

We have multiple Security Groups, such as the following:

Site1-ShareDrive
Site2-ShareDrive
Site3-ShareDrive
Site4-ShareDrive
Site5-ShareDrive

Within said security groups we have users who might not natively be in that Site's OU, as some manage multiple sites, or move around often and need multiple sites within their division.

Example:

Site1-ShareDrive
├── User13
├── User20
├── User33
├── User42
├── User51

Site4-ShareDrive
├── User13
├── User22
├── User23
├── User1
├── User5
├── User3
├── User100

Site9-ShareDrive
├── User13
├── User22
├── User23
├── User1
├── User53
├── User54
├── User545

AD Structure:

All Sites
├── Division-1
|   ├── Site 1
|   ├── Site 2

├── Division-2
|   ├── Site 3
|   ├── Site 4
|   ├── Site 5

├── Division-3
|   ├── Site 6
|   ├── Site 7
|   ├── Site 8

├── Division-4
|   ├── Site 9
|   ├── Site 10

For Group Policy we would like to place the policies at the "All Site" level to theoretically trickle down to the entire structure, but only have them applied based on if the users are in the security group being targeted

Issue

Within Group Policy we are creating new policies for each site that have an item-level target to that specific site's security group

For example:

User1 belongs to the following groups:

Managers
Site1-ShareDrive
Site9-ShareDrive

User 13 belongs to the following groups:

Partner
Site1-ShareDrive
Site4-ShareDrive
Site9-ShareDrive

Logically, the following should be our setup:

• User1 should only have access to \\example.com\Shares\Site1 and \site9
• User13 should only have access to \\example.com\Shares\Site1, \site4 and \site9

Unfortunately, this problem exists on a much larger scale when you add in the fact that some users who might be managers only need one site, where as other managers might need more sites and partners access to their division they are in charge of. The other issue we are running into is some sites are a cooperation between divisions, which is why some users outside their division OU need access to another division sites share drives. Aside from adding them to these security groups going down to the file level for NTFS permissions at this time will be a nightmare, as we are using an old NetApp appliance that actually is being EOL soon by our vendor. We have no timeline on when we will be migrating to a new platform yet.

Additionally

We would prefer to hide any folders that users don't have access to. In the example above, for example, User1 would not even know about the existence of \example.com\Shares\Site8 since the user doesn't belong to the respective security groups

We would like to be able to apply some security groups according to the site the user needs. Along with placing an item-level target on that security group. Our current OU structure resembles the following:

Example OU structure

All Sites
    Site 1
      User13
    Site 4
      User1
    Site 9
      User545

Questions

1. How can we ensure that our structure works with Item-Level Targeting? (i.e. GP: 'Site1-ShareDrive Access' would have "\example.com\shares\Site1" drive being mapped via "Update" and "Reconnect" Checked, along with "Run in user security context" and "Item-Level Target" set to "Site1-ShareDrive", with it linked to "All Sites")?
2. If some of the above are not possible, how can we ensure ease-of-use for our users, while increasing IT productivity?

I created an EC2 instance on AWS, and I was assigned a default "security group". I understand that this acts as a virtual firewall for my server.

I had trouble connecting into this EC2 instance using SSH, and it turned out that the issue was not setting the "Source" to 0.0.0.0/0 in the security group's "Inbound Rules", as shown in the image below.

Is it safe to keep it like this or should I restrict the source to the IP of my home network?

Nobody can ssh into my EC2 instance without the *.pem file, right?

I have a Windows Server 2012 R2 that is my domain controller. I want to disable the password complexity rule for a few users only. I have created a group (called Formation) in AD to identify these domain users. I have defined a GPO in an OU to disable the password complexity rule, and I have assigned my new group to this GPO.

I was hoping this would work, but when I go (on the same server) to manage the users in AD, I try to initialyze the password, but I still get the error message saying the password complexity rule was not followed.

I tried to run gpupdate /force but no success... What else should I look for to fix this?

The password policy is a computer config and I want to apply this to users, is this part of the problem?