The Certificate Enrollment Policy Web Service (CEP) and the Certificate Enrollment Web Service (CES) were introduced with Windows Server 2008 R2 in order to simplify the request for certificates, especially for devices that were not member of a Active Directory domain.
The “classic” way of requesting a certificate from a Active Directory Enterprise CA involves LDAP and RPC/ DCOM, which was okay in the early days of Active Directory, but today, with a CA as a tier 0 asset, this is some kind of a problem.
Usually I tend to use the iPhone WiFi hotspot feature. But lately, I had to switch to USB tethering, because I had to work a whole workday using the hotspot feature. USB tethering saves battery and the connection was more reliable for me. Please note, that you need to install iTunes to use USB tethering, because the necessary Ethernet driver is only available with iTunes. Without this driver, Windows won’t recorgnize the iPhone as an Ethernet connection.
While chilling on my couch, I stumbled over this pretty interesting Reddit thread: Story Time - How I blew up my company’s AD for 24 hours and fixed it : sysadmin (reddit.com)
Long story short: A poor guy applied some STIG hardening and his Active Directory blew up. Root cause was disabling RC4, which caused Kerberos failures, primarily documented by errors like “The encryption type requested is not supported by the KDC.
In the previous blog post I have showed you how to interactively log in into the Microsoft Graph API. You had to enter a username, a password, and you had to enter a second factor. This is typically not want you want if you want to automate things. But there is another way to get access to the Microsoft Graph API.
Create an app registration To get access, you have to register an app in your AzureAD.
There is a new API in town… naa, not really new, but the Microsoft Graph API will replace most, if not all, other Azure AD/ Microsoft 365 APIs. Actually, Microsoft has planned to retire Azure AD Graph API and ADAL in Juni 2022. Now they have postponed this date to somewhere after December 2022. This will give you some extra time to refactor your PowerShell scrips and move them to use the PowerShell SDK for Graph.
Scrolling through my Twitter timeline is a common task to start my day. This morning, a tweet from @BleepinComputer has caught my attention.
Microsoft rolls back decision to block Office macros by default - @sergheihttps://t.co/9BK0slNuEw
— BleepingComputer (@BleepinComputer) July 7, 2022 My first reaction: WHAT. THE. FUCK?! Microsoft added this as feature 88883 in februrary 2022 to the Microsoft 365 roadmap, and I was pretty happy about this feature. Let’s take a look at this change.
A customer used PRTG Network Monitor to notify him in case of account lockouts. This worked quite well until we implemented Admin Tiering. In order to get a mail notification in case of an account lockout, or other security-relevant events in Active Directory, I customized some scripts from my PowerShell dump.
The solution is pretty simple: I used the Task Planner to run a PowerShell script if a specific event id occurs.
Today I faced an interesting problem. A customer told me that their Exchange 2010, which is currently part of a Exchange cross-forest migration project, has an issue with Outlook Web Access and the Exchange Control Panel. Both web sites fail with a white screen and a single message:
440 Login Timeout
I checked some basics, like certificate, configuration of the virtual directories and I found nothing suspicious. Most hints on the internet pointed towards problems with the IUSR_servername user, which is not used with IIS 7 and later.
As part of a Office 365 tenant rebuild, I had to move a custom domain to the new Office 365 tenant. The old tenant was not needed anymore, and the customer had to move to a Non-Profit tenant for compliance reasons. So the migration itself was no big deal:
disable AzureAD sync change UPN of all users remove the domain connect the domain to the new tenant setup a new AzureAD sync assign licenses time for a beer That was my, honestly, naive plan for this migration.
I just had a Teams call with a customer to resolve a strange mystery about Azure MFA.
The customer called me and explained, that he has a user with Azure Multifactor Authentication (MFA) disabled, but when he logs in with this account, he is asked to setup MFA. He setup MFA and was able to login according to their Conditional Access policies.
The customer and I took a look into their tenant and checked a couple of things.
