Not sure what you mean with realtime. Using Account will also be realtime, no delay anywhere.
Storing the password twice is both not possible (since you don't get it from the AD) and bad practice.
But maybe this is a solution: Place the extra fields in an entity (say ‘Person’) having a 1-1 association with entity ‘User’ instead of ‘Account’.
I mean when a user tries to log in, the app should authenticate him/her against the AD, not against the User entity within the application. Is it possible?
Getting user information from an external system and granting them access to your app are two different concepts (user provisioning and authentication, respectively) and both can be performed using something like AzureAD.
It seems like you have solved user provisioning, so you need to fix authentication. This is commonly done by importing an app store module with the correct technology and configuring it. Some authentication modules are SAML (has platform support), Kerberos (deprecated) and OAuth (community support). Other options, such as OpenID Connect have no app store module yet. The modules (SAML, OAuth) work by redirecting the user from your application to the AD, where the user will enter his password. AD then redirects the user back to your application where the module ensures the user is granted access. Therefore, you do not need to know the user's password in your application, but you do need to trust an external application to tell your Mendix who a user is – and that is what these modules do.
These modules contain documentation how to set them up. However, you should check with the engineers of your AD what technology can be used for authentication.