Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

Archive for the ‘Microsoft Authenticator App’ Category

(2019-12-12) Delivered Session About “Moving Towards Passwordless Concept”

Posted by Jorge on 2019-12-12


Delivered session @DetronICT, invited by @ThierryVos about "Moving Towards Passwordless Concept" (preso and demos). About 30 tech enthusiasts listened until bitter end. Thanks for the invitation, and until a next time! Reward afterwards? Enjoying some beers together!

image

Figure 1: Initial Slide – Title/SubTitle

image

Figure 2: Introducing Me

image

Figure 3: The Agenda

image

Figure 4: The Agenda With Demos

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Domain Services (ADDS), Active Directory Federation Services (ADFS), Azure AD / Office 365, Azure AD Connect, Azure AD Identity Protection, Azure AD MFA Adapter, Azure AD Password Protection, Conferences, Field Experiences, Group Policy Objects, Last Logon Information, Microsoft Authenticator App, Multi-Factor AuthN, MVP, Password Expiration Notification, Password-Less, Passwords, Passwords, Self-Service Password Reset, SSO, SYSVOL, Tooling/Scripting, Windows Azure Active Directory | Leave a Comment »

(2019-08-01) Moving Towards The Password-Less Concept – One Heck Of Journey And Badly Needed

Posted by Jorge on 2019-08-01


Current passwords are potentially weak and any use of those in general further weakens an infrastructure. Preferably any org needs to move away from using passwords as much as possible. This means for example preventing the usage of passwords, and instead use SSO and/or other more secure authentication mechanisms. In other words, the adoption of the "Password-Less" concept. However, for those scenarios that cannot adopt “Password-Less" (yet), passwords must be strengthened or better secured at rest and in transport. In today’s world “identity” is the key control plane. Therefore protecting the “identity” and everything related is of utmost importance. Usage of weak passwords presents unacceptable security risks to any org. We all know that, don’t we?! Now you need to act to secure yourself as best as possible.

Going password-less is a journey on its own and implementing that concept could mean for example (NOT an exhaustive list and also in random order!):

  • Ban “weak/common” words from being used in weak passwords using Azure AD Password Protection and/or LithNet Password Protection For Active Directory (LPP) (last one is free and the feature set is huge!)
  • Check AD for weak passwords and weak accounts configurations and follow up with risk mitigating actions. Can be done through LPP and DS Internals and generic LDAP queries
  • Help and educate users in terms of using, storing, generating, uniqueness, sharing/distributing, etc. for less frequent (complex and long) and regular used (pass phrases) passwords. Preferably use machine generated passwords as those have no human logic in them, or use (long) passphrases or bang your head against the keyboard multiple times while on and off holding the SHIFT key (last one, kidding!) (people tend to implement logic or sequences somehow in passwords to not forget those long passwords and to make them unique)
  • Move service accounts in AD from regular service accounts to:
    • Group Managed Service Accounts if possible
    • …and if that’s not possible have a password vault store, manage and change passwords on a regular basis
    • …and if that’s not possible keep using regular service accounts with long and unique passwords
  • If possible, increase the password length to a minimum of 15 characters for users
  • Move away from periodic password changes to risk based password changes (e.g. through Azure AD Identity Protection)
  • Using strong and unique passwords for every individual system/site not supporting SSO (the strength of a password is mostly determined by its length, the longer the better!);
  • Securely store passwords in an MFA enabled password manager/vault that is available on both your desktop and mobile device(s)
  • Make Self-Service Password Reset available to users for those occasions where the password is needed but the user has forgotten the password or has locked itself out
  • When using ADFS, implement extranet lockout policy
  • Only use HTTPS connections (at least TLS1.2) in your environment and do not use HTTP
  • Update systems, tools, scripts to NOT set weak/generic/well-known password or account configurations (e.g. LM Hashes, Password Not Required, Password Never Expires, etc)
  • Decrease the use of passwords as much as possible by:
    • Implementing SSO
    • Implement password-less authN for Windows computers (e.g. Windows Hello for Business) and remove password based authN if possible
    • Implement password-less authN for mobile devices (e.g. Azure AD MFA + AuthNtor App Notifications And OTPs) as primary authN, preferably with at least 2 factors during that primary authN, or implement password authN as secondary authN (when using ADFS)

Additional Resources:

Hope this helps you!

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Domain Services (ADDS), Active Directory Federation Services (ADFS), Azure AD MFA Adapter, Azure AD Password Protection, Kerberos AuthN, Microsoft Authenticator App, Multi-Factor AuthN, NTLM AuthN, Password-Less, Security, Self-Service Password Reset, SSO, WH4B, Windows Azure Active Directory, Windows Client, Windows Integrated AuthN | Leave a Comment »

(2019-07-15) Reenrolling Your Mobile Device

Posted by Jorge on 2019-07-15


the This post is based upon my experience with an iPhone or iPad enrolled in Intune and configured to use the Microsoft Authenticator app. No experience (yet) with an Android device.

Now imagine this, you have enrolled your mobile device (iPhone/iPad) in Intune for MDM and you have installed the Microsoft Authenticator App to support Azure AD MFA (Cloud) for your company account and most likely, or better yet “hopefully” any other account that supports the Microsoft Authenticator App. Looking at myself, when I find a system for which I have an account that supports the Microsoft Authenticator App I configure that account to use it. So far I have added about 70 accounts to the Microsoft Authenticator App.

At device level it has been configured to create a backup of the mobile device (iPhone/iPad) to my iCloud account. At Microsoft Authenticator App level, I also configured it to make backups on a regular basis to my iCloud account.

After using your mobile device (iPhone/iPad) for quite some time, it is either stolen, broken or lost. Solution? Get a new mobile device (iPhone/iPad) and restore it from the iCloud backup.

By restoring it from the an iCloud backup the MDM registration gets wiped, so you will need to register it again. By restoring it from the iCloud backup, the mobile device (iPhone/iPad) inherits the same name from the device from which the backup was created. If you reregister it again, you will end up with an additional device having the same name as the previous one. Now which device can be removed when both the previous and new mobile device have the same name?

After restoring the backup of the Microsoft Authenticator app from the iCloud account, all the accounts in the Microsoft Authenticator app will continue to work, except for any Microsoft-based account (Microsoft Account/Windows Live/Outlook.com/hotmail.com. etc. or Azure AD) as that account needs to be reactivated by re-scanning the QR-code. Just taking the Azure AD account into account, and assuming you are using the converged experience for registering SSPR/MFA security info, you will again end up with 2 registrations (the previous and the new one) having the same name for the mobile device (iPhone/iPad) that has the Microsoft Authenticator app installed.

So to be able to recognize the new mobile device (iPhone/iPad), your best bet as A USER is to change its name after the iCloud restore and before the registration of the mobile device (iPhone/iPad) in Intune and before the re-registration/re-activation of the Azure AD account in the Microsoft Authenticator app for MFA. If you do this and after that re-register in Intune and re-register/re-activate the Azure AD account, you will be able to distinguish the new mobile device (iPhone/iPad) from the old mobile device (iPhone/iPad) and remove the old registration. An admin is able to see the difference in Azure AD of registered devices by looking at for example the registration date and last activity date.

Now, also let’s assume you did not change the mobile device’s (iPhone/iPad) name and you went straight to re-registering it in Intune for MDM and you also re-registered/activated the Azure AD for MFA in the Microsoft Authenticator app. Currently to be able to distinguish the registration of the old and new device for both Intune and Microsoft Authenticator app, that is not possible with changing its name afterwards.

You can do that by following the next steps (based upon my own experience):

Changing name in Intune:

  • Open the Company portal app
  • Sign-out and really close the Company portal app
  • Close the Microsoft Authenticator app
  • Rename mobile device (iPhone/iPad) in iOS
  • Open the Company portal app and sign-in
  • Navigate to the Device section (no need to rename the device name in the Company Portal app itself)
  • Push down for update multiple times until the original name property at the bottom displays the same name as the name you gave it in iOS
  • Also in the Device section, tap “Check Settings” (if you have more than one device registered, select the correct device first)
  • Now if you navigate to the registered devices page (#/device-list">https://myprofile.microsoft.com/?tenant=<tenant ID>#/device-list), you most likely will see the new name of the device. Any mobile device with the old name could be removed from the device list.
  • Delete the registration of the device with the old name(s) for the same mobile device (iPhone/iPad)

Changing name in the registration of the Microsoft Authenticator app in the security info (converged expererience)

  • Navigate to the security info page (">https://mysignins.microsoft.com/security-info?tenant=<tenant ID>)
  • Reregister the Microsoft Authenticator app as a new method (it may be already registered and there is no need to remove it first as you do not know which to remove)
  • Open the Microsoft Authenticator app and readd a Work or School Account, scan the QR-code and complete the registration
  • On the security info page, after reloading it, one of the previous names will have changed to the new name
  • Delete the registration of the Microsoft Authenticator app with the old name(s) for the same mobile device (iPhone/iPad)

Now if you really liked the previous name of the device, just follow the exact same steps above and when you reach the step of renaming the device in iOS, reuse the previous name.

@Microsoft: Please make it easier for users to see differences of old and new registrations in both Intune and Azure AD security info . Add something like a registration date, last activity date, a unique ID that can be easily found in Intune / Security Info, etc. Main reason: empower the user to manage its own info and actually make it easier for them. THANKS!!!

Hope this helps you!

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Intune, Microsoft Authenticator App, Mobile Devices, Multi-Factor AuthN, Windows Azure Active Directory | Leave a Comment »

 
%d bloggers like this: