OK, the title has a whole bunch of acronyms which may not be entirely familiar. Actually…if we’re being really picky I should probably say a whole bunch of initialisms, but that would digress into a whole different article when a perfectly good Wikipedia article already exists for that. 🙂
Anyway, PTA is the accepted short form of Pass-Through Authentication – one of the range of authentication options available with Azure Active Directory.
AADJ stands for Azure Active Directory Domain Join(ed). This is a state for a Windows 10 machine in which it is joined to Azure Active Directory for a given tenant organisation. It is materially different to Azure AD Device Registration and Hybrid Azure AD Join, as neatly described here.
If you’re already set up with Azure AD Connect, have AADJ devices and are using PTA for your user sign-ins then you should be aware of an important limitation with respect to the “User must change password at next log on” flag. The flag itself is set on the user object in on-premises Active Directory. If you’ve been around a while, you’ll already be familiar with the setting – it looks like this:
The setting is used in a number of organisations to deal with the following situations:
- User has forgotten their password and the Service Desk assigns them a temporary password to get them going again
- New hires who are assigned a temporary password to start them off
So what’s the problem with setting this flag in our PTA, AADJ scenario? Well, quite simply the user won’t be able to sign-in to their Windows 10 machine. Instead of the user being prompted to change their password when entering the credentials that include the temporary password, the user sees the generic, “The user name or password is incorrect. Try again”.
Hopefully Microsoft will provide a resolution to this in the near future. At the time of writing the behaviour is seen as “by design” in so far as the error generated on the DC to which the credentials have been passed cannot be successfully translated back to the point where the sign in attempt occurs.
I wonder if that is due to an equivalent flag getting set on the AAD side. I don’t have ad AADJ machine to try it on, but I wonder if this solution would affect that behavior:
https://support.microsoft.com/en-gb/help/4056251/free-busy-lookup-fails-from-exchange-on-premises-to-exchange-online