Cloud Kerberos - Failed to read secrets from the domain
Hi all, Apologies if this is the wrong place to post this! I am looking at understanding Cloud Kerberos and the uses behind it, primarily for WHfB for now. Following the guide on the Microsoft page, I get an error when running on the DC Passwordless security key sign-in to on-premises resources - Microsoft Entra ID | Microsoft Learn Set-AzureADKerberosServer : Failed to read secrets from the domain DOMAIN.LOCAL. The lab environment has 2 DCs at different sites but replicate between each other without issue. The process creates an entry in AD but when I run the command below (GA details is an address, just changed for the forum post) Get-AzureADKerberosServer -Domain $domain -UserPrincipalName "GA details" -DomainCredential $domainCred I get the output below... Id : 16451 UserAccount : CN=krbtgt_AzureAD,CN=Users,DC=DOMAIN,DC=LOCAL ComputerAccount : CN=AzureADKerberos,OU=Domain Controllers,DC=DOMAIN,DC=LOCAL DisplayName : krbtgt_16451 DomainDnsName : DOMAIN.LOCAL KeyVersion : 1598799 KeyUpdatedOn : 27/07/2024 06:41:15 KeyUpdatedFrom : PDC.DOMAIN.LOCAL CloudDisplayName : CloudDomainDnsName : CloudId : CloudKeyVersion : CloudKeyUpdatedOn : CloudTrustDisplay : Can you advise why the secrets aren't being found and the cloud information not populated? This is a lab enviroment so if needed, we can get a bit rough with it. Any help would be welcomed. Kind regards Tom
Moving Microsoft 365 authentication to Entra ID Cloud Auth from On-Prem ADFS
Hi Identity Brain Trust, Assuming this would be the right place for my question as I couldn't find any other hub more relevant for this one. We have several applications configured to be authenticated via ADFS. We are looking to move these gradually to Entra ID Cloud auth and decommission ADFS, eventually. I would like to test out how Microsoft 365 can be moved to Cloud Auth from ADFS for a certain group of people. I have tried to use ADFS migration wizard in Entra but 365 app is not showing in the ADFS Application Migration section of Entra ID. I've read this official guide but still couldn't find how this can be manually done when App Migration section won't have the app appearing there. -https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/migrate-ad-fs-application-overview Appreciate any of your inputs on this one! Kev
B2C Support for on behalf of (OBO) flows
Hi all, this is maybe a question for the Entra ID product group. Does anyone know a rough timeline when there will be support forOn-Behalf-Of (OBO) token flows in Azure B2C or Entra External ID? According to this Documentation, at the moment OBO flows only work for applications registered inEntra ID. Kind Regards ChrisWhenever login into the office applications different OTP needs to be applied Outlook and teams
When signing into Office applications, adifferent OTP is required for both Outlook and Teams. To address this issue, there is any resolution this issue supports or a supporting document as proof to confirm that this is a standard procedure.
Is it possible to protect the Primary Refresh Token (PRT) if attacker has hands on keyboard
Hi everyone, I want to ask if anyone know if possible to defend against pass-the-prt attack? We are about to embark on a journey to deploy privilege access workstations to all IT admins with more or less no internet access. The idea is to have a clean source and heavily reduce an attacker getting hold of the credentials / PRT of an admin account. But because it is so heavily locked down it is already causing issues for us. So I want to find out how big of an issue it is if an attacker was able to get a foothold on a device which is used by a standard user account that has Microsoft Entra ID roles assigned via PIM. So we have Defender for Endpoint installed on all devices, Tamper protection is on and the ASR rule "Block credential stealing from the Windows local security authority subsystem (lsass.exe)" is set to block. further to that we require a FIDO2 security key for all IT admins and CA policies are set to require both MFA and a compliant device. But as mentioned above, if an attacker gets a foothold on a device used by an IT admin user who logs in with his or hers standard account and elevate into an Entra admin role, is it game over by then? If that is the case, it seems to me that the PRT is the weekend and we would be better off not having the device used for admin privileged joined Microsoft Entra.
Block standard C:\Users\%User%\AppData\Local\Microsoft\WindowsApps Path environment variable
Hello togehter, for security reasons I like to block (GPO?) / delete the standard Windows-path-enviroment variable: C:\Users\%User%\AppData\Local\Microsoft\WindowsApps First of all: Does it make sense to do this? I want to exclude a case that some user / unwanted software are copied here by attackers. Thanks a lot KevinUI Risk with MFA configuration
Hi all, As we discovered recently to our cost and inconvenience - the UI layout in Conditional Access, specifically the Grant\Require Authentication Strength poses a two-part risk if an admin isn't paying enough attention. The combo-box presents all 3 options like so: Which can lead to the bottom entry getting clicked on accidentally; but also - because it's a combo box - if someone accidentally knocks their scroll wheel for instance, or applies a scroll down gesture on a touch pad - it can easily slip down to the bottom entry for FIDO2 keys. Which leads to the second part of the risk. As we discovered earlier this month, the system may not (or possibly will not, we can't confirm either way) allow users to register a FIDO2 key AFTER the config has been set as you can't successfully login. The CA system (or at least this specific clause) shouldabsolutelyhave some kind of logic check that would bar the enablement of the clause if no user objects have a FIDO2 key registered. Not only would this save a great deal of frustration on the part of clients using Azure, but also alleviate some of the call volume which the data operations/data engineering team that handles lockout scenarios seems to be suffering with. Our issue took 2 weeks to resolve, 13 days of which was spent waiting for the team to have availability - as we'd gone through all the initial hoops for verifications, testing etc within the first 12 hours or so of the problem occurring.
