We would be hosting a chill conversation session about security but we would like your help and support to FOLLOW and be a member of UniQ Consulting and Services.
Good day everyone. Even with the Covid-19 is rising drastically in Malaysia, kind of brings my hopes down. Anyway, I still have to keep going with life.
Today’s topic is about the Azure’s conditional access policy. We found a bug in conditional access for iOS device platform. So basically our situation is that, if we would need the conditional app control to be functioning in the Cloud App Security, we would need to setup a conditional access policy. Our setup was only to achieve monitoring mode only. However, after enabling the policy we retrieve reports saying that all iOS devices are having trouble accessing their exchange online. Users are receiving an email notification, stating that their exchange online access is being blocked. We had to disable the policy temporary to troubleshoot it.
This was the email notification:
- This was our configuration for the conditional access policy;
- Assignment: Include a test group, Exclude the VIP accounts
- Cloud apps: All cloud apps
- Conditions: None
- Session: Use conditional app control (Monitor Only)
So this is the Microsoft article shows how the configuration/enablement is being setup in the conditional access in order for the app control to work, as you can see there weren’t any conditions being setup. Hence, it should not be doing any requirements checking or blocking.
To be honest, I had raise ticket to MCAS, Exchange Online and Azure team, and none of them able to get back to me an answers. MCAS team state that “no conditions are setup it SHOULD NOT be performing blocking”.
I had to stop relying the Microsoft Support for this case, as I had to find a way to identify it. So based on the image above, we can see that the article is not mature enough, because there weren’t any solid references or notes stating the limitations/restriction of monitor only of conditional app control.
Upon further checking, I had to analyze the logs of Azure Sign-in activity and Cloud App Security Activity log of that user whom experience the issue. We notice that the sign-in was shown as “Interrupted” and there was no failure sign in status. For your information, the iOS version is 14.
Error code 1: This is not an error – this is an interrupt that triggers device authentication when required due to a Conditional Access policy or because the application or resource requested the device ID in a token. This code alone does not indicate a failure on your users part to sign in. The sign in logs may indicate that the device authentication challenge was passed succesfully or failed.
Error code 2 : This is an expected part of the login flow, where a user is asked if they want to remain signed into this browser to make further logins easier. For more details, see https://techcommunity.microsoft.com/t5/Azure-Active-Directory/The-new-Azure-AD-sign-in-and-Keep-me-signed-in-experiences/td-p/128267
Error code 3: 50097
Another finding was that there weren’t any Exchange mobile device access policy/rules being configure to perform the blocking.
I do know that once this conditional app control is enabled there will have this prompt page before entering into the Exchange online, this is my iPad Air by the way, running on the latest version. The prompt page can be turn off though. Anyway, that is not the case here. I ran a test to mimic the situation but I didn’t experience any email notification send to me stating my exchange online access is being blocked. There is no MFA or Biometric setup on my iPad.
The questions still lies is there a pre-requisites for iOS devices for conditional access policy, even though there is no conditions being set?
Below is image from web browser;
Below image from my iOS outlook app;
Ok so recently been receiving reports about users experiencing their outlook keeps flashes white pop-ups and remain disconnects, even their Internet is connected.
It seems this issue only occurs to users that never or frequently perform updates on their machine and office apps.
The solutions was to perform windows update and Office apps update to resolve this issue, if you have driver update, do perform that too.
If the issue still occurs, then you have to dig into the event logs to identify the issue. If time is limit, then you just proceed to uninstall and reinstall their office apps.
Hey guys and girls, how are you all doing working from home? Please stay safe and keep your distance.
Today’s topic is about creating multiple root certificate in a single forest, please take note that this is not a best practice by Microsoft but it was the right solutions for my situations. There will not be errors/stopping you to proceed, if you setup multiple root certificate authority.
So basically I have this tested on my lab only I proceed into production. Whenever you aren’t confident about the solutions please always run your lab. Don’t give people heart attack. Active Directory is a sensitive being.
My situation is that we have existing Windows Server 2008 R2 and is moving to Windows Server 2019, currently there is a root certificate authority siting in Windows Server 2008 R2 and would like to transition to Windows Server 2019 without downtime. Hence, Migrating is not the right word for this situation, because Migration required downtime. Imagine people working from home unable to VPN access into the work environment. You will get the scream and shout by them, Good Luck.
For having a multiple root CA, so that at the network layer/firewall layer, the network administrator can create another certificate access for user to VPN access using either the old Root CA or new Root CA. Hence, zero downtime.
Step by Step:
- You have to add the roles and feature into your Windows Server 2019
- Once you have the role installed and the configuration setup (just follow the default configuration, please choose Enterprise Root CA)
- Make sure your instance naming or certificate authority name is not duplicated with your other certificate authority server name
- This is the result of successful setup of the certificate authority
- So now you got to make sure the certificate authority server has its certificate propagate on its local machine too
- Launch Start > Run > mmc
- MMC > File > Add/Remove Snap-in… > Certificates
- Certificates > Computer account > Local computer > Finish
- Certificates (Local Computer) > Expand the folder > Personal > Certificates
- Certificates (Local Computer) > Expand the folder > Trusted Root Certification Authorities > Certificates
- Because now the forest has 2 Root CA, so your trusted root CA folder would have 2 Root CA certificate
- To export the new root CA certificate to your network administrator, Launch your command prompt on the Root CA server > run the following command
- certutil -ca.cert <filename>.cer
- To allow the other server members of the forest, please access to the server and follow step 6 to step 9, remove the old Root CA
- Then run a gpupdate /force command line > Reboot the server, to have the changes reflected
- Perform a checking whether the changes has reflected to the other server(s) after performing step 13 to 14, please access to their local computer certificate and check. Repeat step 6 to step 10.
- Do not export the Root CA certificate and import to the servers, because this would beat the purpose Enterprise Root Certificate Authority
- If you have a larger environment it would take awhile for the change to replicate. Hence, continue the gpupdate /force until you receive the result you wanted on the server
Hey guys and girls, hope you all are having a good day. Today’s topic has a relation of 3 platform.
- Intune/Microsoft Endpoint Manager
- Outlook App (Windows)
This topic is more related to migration situations, so basically the environment is running IMAP and are on the stage of migrating to Office 365. Hence, to allow users to able to proceed to make use of the new mailbox and having to receive latest emails without disruption or downtime, would need to create the office365 email account on their Outlook profile.
If you notice that you have an email account, email@example.com with the type “IMAP” on your outlook default profile, but you would like to also add the firstname.lastname@example.org with the type “Microsoft Exchange” on the outlook default profile too. This is where the issue happen, majority would just proceed to try to add the account from the Outlook app but it will never let you successfully add the new account in and return with the message saying “This account has been added.” It seems to me that the Outlook App unable to differentiate TYPES. If you dig into Google Search you will only get articles, guiding you to create a new Profile just for the Office 365 account.
Wait…there is a solution to this. Please don’t bother raising case to Microsoft Support from Intune, if you’re lucky you will meet a support that willing to go extra miles for you. Usually the support would recommend you to turn on this feature from Intune “Automating the creation of outlook profile for Exchange Accounts” this only applies to new profile not existing profile.
So basically the solution is simple but I’m still unable to find an automation way to perform this. Hence, manually, but luckily is was just a small business organization, else I’m poof of words. Just type organization that is not willing to spent other migration products such as BitTitan and etc..
Anyway, to create an email account o the default outlook profile we would need to
- Launch your Start/Windows button
- Search for “Control Panel”
- Search for “Mail” in Control Panel
- Select the Mail > select “email accounts”
- Then select “New”
- Enter the following details and click Next
- Wait for the establish processing…
- You will now have 2 email@example.com accounts in the default Outlook Profile with different types, IMAP and Microsoft Exchange.
If you are still wanting to go with having 2 profiles in Outlook to serve each types here is a simple PowerShell Script that you can upload to Intune;
#This is to create new Profile with the new Profile name
New-Item -Path "HKCU:\Software\Microsoft\Office\16.0\Outlook\Profiles\<Profile Name>" -Value ""
#This is to allow the prompt to users to choose which Outlook profile
Set-ItemProperty -Path "HKCU:\Software\Microsoft\Exchange\Client\Options" -Name "PickLogonProfile" -Value "1"
Hey guys good morning! Is a rainy day today, just brings the relax mood on.
Here is another topic on Microsoft Defender for Identity, is the troubleshooting on sensors.
When you notice that your sensor keeps disconnecting, while it was fine during the first 2 weeks of the deployment.
There are many possibilities that causes this issue, so I’m glad that there is this Sizing tool that you can use to identify the traffic on the domain controllers and it will provide you recommendation of the hardware requirements that needs increasing or look into it.
Sometimes this is not due to domain controllers or the sensor issue, it could meant that the environment is growing and numbers of applications required the LDAP authentications with the closest domain controllers or the FSMO holder domain controller.
This is how the alert looks like on the ATP portal;
To proof that whether the domain controller needs increment of the hardware resources
- Download the sizing tool
- Install the sizing tool on the domain controller that has issue with the sensor
- *it does not require restart of domain controller
- Run the application for 24 hours
- It will export a excel file on directory of the application
This is how the reports looks like, filename is TriSizingToolResults_<date>
As you can see above the I have 3 domain controllers that exceeds 30k of packets per second, and it recommended me to increase the RAM size.
Below is a diagram of requirements needs to be meet;
I highlighted ones is needs to be met for my 3 domain controllers.
Hey guys hope you are doing well!
Now let’s start off with a topic related to on-premises, which is domain controller. I had encounter a weird situation where I was performing a domain controller migration from a Windows Server 2008 R2 to Windows Server 2019, during the migration process I wasn’t able to proceed to active directory domain services in Windows Server 2019.
I had all the prerequisites checked but this was the first time I have ever encounter this.
This was the error that I encounter during the wizard…
“Verification of replica failed. The specified domain is still using the File Replication service (FRS) to replicate the SYSVOL share. FRS is depreciated.”
The error explains that the SYSVOL is running a depreciated service, called FRS and recommended that I perform a migration of FRS to DFSR.
SYSVOL is basically a folder that contains your Group Policy Management and Scripts and it replicates to all other domain controllers. SYSVOL folder located in C:\Windows in your domain controllers.
FRS is basically the service to perform the replication. Upon research, FRS only supports Windows Server 2000 and 2003 only. Windows 2008 and above depreciate FRS. However, how in the world that FRS is running on Windows Server 2008 R2???
To further investigate this situation, I had to ask whether that the environment has any application servers that is on Windows Server 2003. If the answer is yes, it means that the environment used to be running on Windows Server 2003 or earlier. It seems that the transition/migrate of domain controller was not clean during that time.
There is one article that spoke about the migrate of Windows Server 2003 to Windows Server 2008, doesn’t meaning only migrate the FSMO roles, and majority forgot to migrate the FRS to DFSR. Hence, this FRS was able to carry forward to the Windows Server 2008.
*Note: Below are not detailed steps on how to setup a domain controller, you must at least have knowledge on how to setup a domain controller
The best way to mimic this error was to setup my lab
Why so this transition? Every Operating system works differently.
Make sure you got the right permission account.
- Setting up domain controller permission required domain administrator rights.
- FSMO transfer permission required enterprise administrator, and domain administrator.
- DFSR migration permission required is domain administrator.
- Setup Windows Server 2003 domain controller
- Setup Windows Server 2008
- Adprep the schema in Windows Server 2003
- Make Windows Server 2008 a domain controller
- Migrate the FSMO from Windows Server 2003 to Windows Server 2008
- Decommission Windows Server 2003 domain controller
- Raise domain functional level from Windows Server 2008
- Setup Windows Server 2008 R2
- Adprep the schema in Windows Server 2008
- Make Windows Server 2008 R2 a domain controller
- Migrate the FSMO from Windows Server 2008 to Windows Server 2008 R2
- Adprep the schema in Windows Server 2008 R2
- Setup Windows Server 2019
- Proceed to make Windows Server 2019 a domain controller –> here is where the error happens
Steps on how to perform FRS to DFRS migration
- Always perform System state backup before proceed this on production
- Check the replication health on all domain controllers, make sure are healthy before starting
- On the Windows Server 2008 R2 domain controller that holes PDC role, launch your command prompt as administrator
- Run the following commands
- dfsrmig /getglobalstate
- This means that the service is not using DFSR
- net share
- Under the Share name, SYSVOL’s referring the resource of C:\Windows\SYSVOL\sysvol, we are going to change it to be C:\Windows\SYSVOL_DFSR
- Next, run this following command to start your phases of migration. There are 4 phases of migration.
- Phase 0: Return – This phase is a fallback option for you. This is only useful if you are in Phase 1 and Phase 2.
- Phase 1: Start – This phase allow you to start the migration and prepare the SYSVOL to be copy the content to SYSVOL_DFSR. System created a new folder called SYSVOL_DFSR.
- Phase 2: Redirect – This phase will start to redirect the SYSVOL path/pointer to SYSVOL_DFSR.
- Phase 3 Eliminate – This phase deletes the SYSVOL folder.
- The command to start the phase 1 is
- dfsrmig /setglobalstate 1
- dfsrmig /getmigrationstate
- got to make sure phase 1 is completed only proceed to phase 2
- Proceed to Phase 2
- dfsrmig /setglobalstate 2
- dfsrmig /getmigrationstate
- got to make sure phase 2 completed only proceed to phase 3
- Proceed to Phase 3
- dfsrmig /setglobalstate 3
- dfsrmig /getmigrationstate
- Check the services
- After running all phases successfully, it will automatically disable the FRS services and stop it from running
- Run net share command to check whether the SYSVOL’s resource has changed to the new path
- This migration doesn’t require rebooting the domain controllers afterwards, but if there is a reboot prompt require before the migration, please proceed the reboot first.
- Stopping the FRS services without running the migration, would not help resolve the issue
- If you have child domain, then please also perform a DFSR migration on the child domain’s domain controller that holes the PDC role
Hey every good evening, and hope you guys are having a nice day today. Just another topic about Azure ATP here, a.k.a Microsoft Defender for Identity.
If you come across this before and then you would already know what is it for. If you are new here, then let’s just have a brief explanation what is it about. Azure ATP is basically a cloud-service that leverages your on-premises to perform identifying, detection and monitoring of your domain controller’s user objects activities and behaviors.
Newly deploy Azure ATP in your environment would take 48 hours to 72 hours for the Azure ATP to study the behaviors of each accounts, but this is also depend how large is your objects in your environment.
Anyway, a bit of side track just now. This blog post objective here is that if you ever encounter the 5 types of attacks, Reconnaissance, Compromised credentials, lateral movements, domain dominance and exfiltration alerts from the Azure ATP.
You may refer to this link here to learn how to remediate and understand how to manage the alerts.
Hey everyone, hope you guys are having a nice evening. Today’s blog post is about Azure ATP and Office 365 audit.
So the situation is like this;
Majority Office 365 tenant has more then 1 global administrators. Whenever, a global administrator would like to capture other administrators actions, they would query those events from Office 365 audit. So for Azure ATP, I notice it is not available in Office 365 audit, but for Defender Endpoint it exist in the audit. Summary, you can’t audit actions being taken in Azure ATP portal.
Scenario: If a global administrator, deletes an alerts from Azure ATP, it would remain deleted and there is no recycle bin to restore the alert back unless you regenerate the same situation to trigger the detection. This delete action is not recorded into the Office 365 audit.
I do not see this as a show stopper, I am still testing other ways to get this working. Stay tune…
Hey Hey everyone, good morning, is Saturday here in Malaysia. Hope you guys are doing well. This week blog post is about another Microsoft Defender for Identity, a.k.a Azure ATP. The terms are up to your suit and understanding.
I think is very reasonable to know what is the retention period that the Azure ATP’s Reports. Why? Because of Auditors…
Upon researching to gather articles from Microsoft site and there weren’t an article talking about how long the reports store in Azure ATP. I do know that the reports in Microsoft security max are either 30, 60 or 90 days.
Thus, I had to raised a case to Microsoft Support and they return the answer that the retention period is 180 days. I did request whether they were able to locate any article from Microsoft that state it but none.
To locate Reports in Azure ATP, simply go to https://portal.atp.azure.com , select the 2nd Icon on the left taskbar.