Device Migration from On-prem AD to Azure AD
Hello All, We want to migrate our On-Prem AD devices to Azure AD and enroll into intune. We have Azure AD sync and all but needs to convert machine to Azure AD join only not Hybrid AD. So we would like to create new user profile on machine. We have used two methods so far. 1) Reset the machine and use join to Azure AD from OOBE. ( Issue - This will make user a Administrator for that machine and we dont want that ) 2) Unbind from on-prem AD, join to Azure AD manually but the same issue like number 1. 3) Using Hardware Hash, register devices to Autopilot and then reset all the machines. ( Issue - This will take too long to migrate 250 machines and helping remote workers are quite difficult ) Has anyone tried any different method or is there any expert suggestion ? Thanks!On-prem access from an aad joined device with Windows Hello for Business
Recently one of my clients asked me to setup Windows Hello for Business as part of our Modern IT Management PoC. So currently they are using convenience pin and the use case was that on their Modern IT managed AAD joined devices the users should be able leverage Windows Hello for Business being able to also access on-prem resources when on corpnet. As the client wants to benefit from Azure Identity Protection feature to detect leaked credentials and automatically take action on it (force pw change and MFA) he’s using AAD Connect with Password hash sync enabled. So he’s not using ADFS and already had some Server 2016 DCs inplace. Based on this great Decision Matrix: we decided to go for Windows Hello for Business Hybrid Key Trust. So there are already a couple of great guides on how to set that up here so I won’t to that again: https://blogs.technet.microsoft.com/chadcox/2018/03/19/my-notes-on-setting-up-a-poc-windows-hello-for-business-lab-using-hybrid-key-trust/ https://blogs.technet.microsoft.com/microscott/setting-up-windows-hello-for-business-with-intune/ https://gallery.technet.microsoft.com/Windows-Server-2016-Active-165e88d1/file/182710/1/W2K16%20Active%20Directory%20Certificate%20Services%20Lab%20Build.pdf My client however was a little bit scared as Michael Niehaus wrote on his blog the following: https://blogs.technet.microsoft.com/mniehaus/2018/02/21/afraid-of-windows-10-with-azure-ad-join-try-it-out-part-2/ Ok so we decided to do a quick lab repro to check if we also experience any issues regarding the CRL and guess what…sure we did – so let’s have a look if we can beat Michael working on it for several days 😉 If the user was logging in on his aad joined with his “legacy credentials” (username/pw) he could access on-prem resources and everything was ok, if he was logging in with Windows Hello for Business then the user was not able to connect to the on-prem share and the following error message appeared: So looking at the CAPI2 log in the eventviewer we saw that the client was not able to do the revocation check as the CRL was not reachable. Hmm strange as the CRL was published already externally via Azure Application Proxy (you can find a cool step by step guide over here https://blogs.technet.microsoft.com/microscott/how-to-set-up-azure-ad-certificate-based-authentication-for-office-apps-on-mobile-devices-ios-and-android-part-1/ ). At this point I was involving my PKI colleague Dagmar Heidecker who is an PKI expert as I didn’t want to spend several days 😊 We added the CRL via certutil directly to the client but somehow the client still always tried to access LDAP and internal web server and ran in a timeout. So we changed the CDP/AIP extension on the root and sub ca and removed the LDAP path. Next step was to request and install a new subca certificate and publish the crls. After that I checked that the DC already had the new certificate without the CDP pointing to LDAP. Then I restarted the KDC service on the DC, cleared the cryptocache (C:\Windows\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache\Content and Metadata) on the client and…..whoohoo. On-prem access was working successfully when signed in via Windows Hello for Business! Kudos to my colleague Dagmar Heidecker!
Hybrid Azure AD Join (with ADFS present) question about SCP
Configure hybrid Azure Active Directory join for federated domains | Microsoft Docs The article above has got me curious and I can't find an answer to my questions. I've also opened an issue on GitHub, and have read as many blog articles as I can find, but all that I've found just repeat the info that is stated in the Docs article. In the section Configure hybrid Azure AD join step 6.b states: Select the authentication service. You must select AD FS server unless your organization has exclusively Windows 10 clients and you have configured computer/device sync, or your organization uses seamless SSO. So then, let's say we have all Windows 10, the statement leaves two possibilities: We also have setup Seamless SSO (I assume this means Azure AD Connect's checkbox and related configuration via GPO) We have not setup Seamless SSO, and instead are taking advantage of Windows 10's Primary Refresh Token capability (link) I can understand that if we fall into #1, then we need to select our ADFS for the Authentication Service. But why is that? SSSO involves automatic logon to an internet (Microsoft/Azure AD) URL; it doesn't involve ADFS. For ADFS' own SSO to work, the ADFS STS URL (or FQDN) needs to be added to the Local Intranet zone which needs to be configured for for automatic logon. So SSSO and ADFS SSO are two different things. Therefore, it's not clear why SSSO has any bearing on this choice for the SCP config's Authentication Service. What is the reason for this? Next, if we fall into #2 (no SSSO configured in AAD Connect (and related additional config that goes with it)), why might we choose ADFS over Azure AD? Similarly, why might we choose Azure AD over ADFS? There is one other part of the article that is also unclear to me, again related to the Authentication Service. If we have the Authentication Service set to use Azure AD, do we still need to worry about this ADFS-based pre-requisite?: A federated environment should have an identity provider that supports the following requirements. If you have a federated environment using Active Directory Federation Services (AD FS), then the below requirements are already supported. WIAORMULTIAUTHN claim: This claim is required to do hybrid Azure AD join for Windows down-level devices. WS-Trust protocol: This protocol is required to authenticate Windows current hybrid Azure AD joined devices with Azure AD. When you're using AD FS, you need to enable the following WS-Trust endpoints: /adfs/services/trust/2005/windowstransport /adfs/services/trust/13/windowstransport /adfs/services/trust/2005/usernamemixed /adfs/services/trust/13/usernamemixed /adfs/services/trust/2005/certificatemixed /adfs/services/trust/13/certificatemixed Specifically the WS-Trust protocol.. If the SCP / Authentication Service is pointing to Azure AD, I'm unsure if this requirement is still relevant. I assume the answer to this last part is yes, and the reason for that assumption is the Office 365 relying party trust claim rules that need to be added to support HAADJ. Not sure though if I'm correct on this assumption or not. Does anyone happen to have clarity around this that you can share with me? Thanks in advance.
Block Access from private Devices to Microsoft Apps.
Hello, i got a question: We are planning to Buy Microsoft 365 Business Premium and Microsoft 365 Business Standard + Intune Device License. My problem is that our Company doesn´t want to have Access to Mail/Onedrive/Microsoft Applications ... on private Devices. How can i block the Access? The Devices will be Managed by Intune, Win10 Pro, IOS and maybe some Samsung Galaxy´s. Is There an option to only allow managed devises to Access Microsoft Data? And Do i need some additional Lisense? Best Regards, Phil
Automating Migration from AD to AAD (Non-Hybrid)
I promise I've Googled as hard as I can and can't find the answers to what seem like some pretty simple questions... I've got a bunch of digital signage and point-of-sale devices that I want to migrate from AD/SCCM to AD/Intune. They log in with local accounts. I don't want to mess around with hybrid, I just want to cut them straight over with as little effort as possible. Manual method I'm pretty sure will work: 1. RDP into each one 2. Disjoin it from AD (have to enter a domain account with disjoin privs) 3. Uninstall the SCCM client 4. Use a bulk enrollment provisioning package to join to AAD 5. AAD automatic enrollment to Intune 6. Done This will be a pain though, so I'd like to automate it. I think I can use SCCM to install the AD-join bulk enrollment provisioning package and it shouldn't be a problem using SCCM to uninstall itself and I should be able to configure SCCM's AD discovery to exclude these devices so SCCM doesn't try to re-absorb them while I'm working on disjoining them. Then, finally, I think I can use some powershell remoting and the remove-Computer cmdlet to disjoin the devices and pass in the creds that have privileges. I'd disjoin with SCCM but I don't want to put those disjoin creds in a script. Question: 1. Can I join an AD-joined device to AAD? Can they exist simultaneously for a few days without any hybrid configuration? 2. Is there a better way to do this? Thanks, Dan
Conditional Access rule for Outlook Web exception
Hi, To access O365 apps like Outlook, Teams, OneDrive, SPO we require an enrolled and compliant Windows or iOS device. All external clients are Azure AD joined and Intune enrolled. Now, we want to do an exception for Outlook web access. All computers (web browsers) should be able to access OWA from a non-enrolled computer with MFA. Restrictions for read-only according to the article Conditional Access in Outlook on the web for Exchange Online will be applied to prevent data leakage (but not yet configured) It's not working as we want, we believe it used to work... If we except O365 Exchange Online App in our Desktop Conditional Forward, Web Access is indeed accessible as we want. But, then you can also use a mail client on a non-enrolled Windows 10 to access e-mail.- Only web access should be allowed unless you have an aad-joined and enrolled computer. How do I fix this issue? Thanks /B Conditional Access Rule All users targeted (O365 emergency admin account excluded) All Apps targeted (O365 Exchange Online excluded) Client Apps Grant
