Thanks for the answer.
So now the topic is, are the members of the group "Exchange Trusted Subsystem" able to add/remove Members into the Domain Admins group?
Because when I understand it correctly, the group "Exchange Trusted Subsystem" does only have GenericAll/FullControl to the according ObjectTypes or InheritedObjectTypes?

In this case, the Group has Fullcontrol to:
- 0f8ffac-1191-11d0-a060-00aa006c33ed -> which is publicFolder
- c975c901-6cea-4b6f-8319-d67f45449506 -> msExchActiveSyncDevices
- 018849b0-a981-11d2-a9ff-00c04f8eedd8 - msExchDynamicDistributionList

Or am I wrong here?
I just have to make 100% sure that no one is allowed to change the domain admins group, not even an Exchange subsystem.

Hey @LeonLaude,

I know already that the On-Premise MFA Server is no longer available.

But the question is, can we handle the process of "Multi-factor for (on-premise) RDP Logins and console-logins to windows-servers" with the new "Azure AD Multi-Factor Authentication"?

How does the Azure AD Multi-Factor Authentication work with on premise systems? Can we use this function only for special server administrators or does all users (log in to the same fileserver) needs MFA?
Is the MFA handled with certificates, or also with a Smartphone App?

Thanks for your post.

I know the general process of checking the correctness of user/password: 1. locally, 2. Domain Controller
My main question is, why is the client contact each Domain-Controller in the domain for checking the username? Is this a default behaviour or do we have a problem within our enviroment?
Normally, when a Clients receives "wrong username/password" from one DC, then I would accept if the Client goes to the KDC and ask the KDC-Domain Controller for cross-checking. But why is the client contacting ALL Domain-Controllers?

Thanks for your detailed information.

According your steps, I was still thinking about following topic: When I renew the Root-Certificate (with same keys), is there any need for third-party-application/systems to also renew the root-certificate or are they able to use the new one?
For example: we have non-domain-joined Windows clients, where the root-certificate was added manually into the certificate store. As we renew the root-certificate now, is there also a need to add the "newly" created root-certificate to that client or is there a relationship between "old/expired root-cert" and "newly created root-cert" (we still use same key-pair).
We have a lot of non-windows systems/apps which the root-certifcated was added manually - the point is, do we have to add the new root-certifcate again to all systems or will they by able to work with new certificates (created from new root-cert) without added the new root-certificate?

A little bit complicated, but hopeing you understand my question ;)

JYes, that's really crazy.
I have tested the behaviour: It is even enough, if you use "Remove-DHCPServerv4OptionValue" before you add a new value (with "Set-DHCPServerv4OptionValue").

The curious thing is, that the change is visibile within the MMC/GUI and really available - but after restarting the DHCP-Service the value is changed back.

In my opinion, this is a real bug.
Normally a "set-"command also has to update the existing value.
I have already a ticket opened to microsoft - they investigate the issue if it's a bug or not.
They have been investigating this for 8 weeks now.

Hello @DaisyZhou-MSFT ,

thanks for your response, but as I wrote already " I know, publishing certs to Windows Clients is possible with "autoenrollment". But the main webservers are tomcat and apache."
The problem is not with windows devices, the main part is focussed on thirdparty devices/apps which are also using certificates

We create manually a cert-request (mostly via Openssl) and then input the cert-request manually to the CA (website: certsrv) - afterwards I provide the certificate back to the tomcat and import it there manually.
The question is, does someone knows any managementtool (maybe also thirdparty) to automate such a process.

Hey,

I already tested the behaviour when I do that within the GUI - then all works fine and also after restarting the DHCP-Service all looks good.
So the problem is only while pushing the option with the powershell-command - doing all the tasks manually is not possible in our enviroment.

Hello @RichMatheisen-8856,

yes, the optiondefinition is set before, because 'Option 12' is a default option of a Windows DHCP-Server.

Additional, the 'try/catch' will also not work, because the option12 is set to the DHCP-reservation and can also be reviewed, BUT: after restarting the DHCP-Service, the value is gone.

During the renew-process of the root-certificate, will the old root-certificate be revoked or is it still valid?
I think the main question is: what will happen with (client-) certificates, which were requested with urgent root-certificate? Is the certificate chain still valid or do we have to replace all certificates with the new root-certificate-chain?