Hello @Christopher Teixeira Oliveira ,
I will try to answer this with some assumptions. I am not sure as to why you are using Alternate Logon ID to login but generally AlternateLogonid is used in scenario where we have non-routable domain suffix on-premise in the UserPrincipalname attribute for the users and routable domain is only used in the value of mail. Its the most general use case for alternate logon ID. When you setup Alternate LogonID , it does not mean it will only work with the value in mail attribute (means email address)as username but it will also work with Usserprincipalname as username.
Lets say your onpremise non-routable Domain is contoso.local and routable domain is contoso.com . My answer is based on assumption that the on-premise admin users have a non-routable Domain sufix like contoso.local and hence the userprincipalname value being admin01@Company portal .local . If this is the case you can flip the Userprincipalname for the user in on-premise AD using routable domain whichever is being used for email address which in this example would be admin01@Company portal .com and this should fix your issue as the logon on ADFS page would work.
It may be possible that the userprinciplename attribute is not built by using exact value in samaccountname attribute for the user and may be different like below in the on-premise .
Example admin User object
==========================
displayName : AD admin
samAccountName : admin01
userPrincipalName : adadmin@contoso.local
mail : $NULL
Since you have ADFS and you are using azure , you must have the AD connect sync server as well . In the AD connect server there must be sync rules for user objects which would sync email as Userprincipalname if an on-premise user object has email address defined in mail attribute however if mail attribute is blank then it would build the upn value using samaccountname and email verified domain and send that value as UPN so here the UPN value of admin01@Company portal .com will be sent to the cloud. Now when a user tries to logon to any cloud app like azure portal etc. and the user is redirected to the ADFS page in case of a federated environment like you have, it pre-populates the userprincipalname value to the username field on the ADFS login page . The user may just be only typing the password on this page however when ADFS will try to get the credential validated it will fail because the userprincipalname onpremise is actually adadmin@Company portal .local and not admin01@Company portal .com . If this is the case in your environment, then you may need to fix the Userprincipalname value on-premsie again to {samaccountname}@{verified email domain} and that should solve this issue.
I can think of these two scenarios and the solutions for your environment. I hope I did not miss anything and this answers helps you solve your problem. However if you still see any error please provide more detail with a screenshot of the error and we will help you further. Should any of the answers help , please do accept the post as answer so that it can be helpful to other members of the community with similar queries.
Thank you.