Different QR

[PsySuck]

Hi. I updated ADFSMFA to the latest release and found weird issue: Usage successfully registers the OTP, but the QR is different in mmc. I checked few time. QR from mmc is valid. This does not occur with all users. Also i can't send email - if found error in eventlog: Error Sending Email (KEY) for user ...: Input string was not in a correct format.

I am using: RSA per User. AD as storage.

[PsySuck]

I checked AD logs. it seems TOTP is put 3 times during registration

.

[redhook62]

Hi, @PsySuck

Nothing has been changed about TOTP for quite a while, it's really very weird. When you say this happens for some users, is it always the same users or is it completely random? For advance I would need more details.

• UPN Are there any specifics on the upn? including length or special characters. Can you send me (by anonymizing) the UPNs of the users concerned (replace the chars you want, imperatively keeping the length and the "-_.@" present.
• E-mail Does the user have an email address filled in?
• TOTP Setup can you make me a screenshot of the parameters of the TOTP config? here : MMC TOTP Config Which TOTP Applications are used (MS, Google, Ageis, ....)

You can try to unblock the situation of some users to delete their current key, before creating a new one either by the user or administratively via the console.

regards

redhook

[PsySuck]

I can't find pattern. Some new users have this problem.

UPN: name@a_____.com E-mail: it is empty after registration - i fill it via powershell. TOTP Setup:

We changed 10 days ago hash algoritm from sha256 to sha1 because google authenticator. no matter what authenticator - qr code is different. It can be seen from the audio logs that the MFATOTPKey attribute changes three times. As workaround i am using import-MFAUsersADDS.

Your UPN does not tell me if for example there is a problem of length.

Regarding the TOTP code and the hash version, you can refer to issue "7" of 2018 or possibly issue "98" of 2020. Since version 2.2.18, we correctly handle the issue. For example, if you use "Google Authenticator" or "Microsoft Authenticator", these two Apps onl"y support SHA1, whereas the standard requires SHA1-SHA512, plus or minus 6 digits, and a period greater than 30s.

The GAFAM judged that this had no impact on security... and therefore did not implement the RFC completely... Other Apps like Authy, Ageis fully support the RFC.

The fact that you changed the algorithm from SHA512 to SHA1 is the cause of your problems, because the keys saved in SHA512 are no longer functional. If you set the keys to SHA512 as before, there is no problem at the moment of validation we test all the Hashes starting from SHA512-> SHA1. In this case, whether your App is SHA512 (RFC) compatible or not as SHA1 only, your code will be validated correctly.

Personally, I am in SHA512, 30 Seconds, 6 Digits, RSA per User, and the key is used by Microsoft Authenticator, Google Authenticator, Yubikey Authenticator, Authy and Ageis Authenticator work (MS, Google=SHA1) (Yubikey, Authy, Ageis =SHA512)..

The recommendation is therefore to reposition the hash on SHA512. All old keys (+ 10 days) should work. All new keys (- 10 days) will not be valid and must be regenerated (we do Top-Down to validate keys and not the other way around)

let us know.

regards

[PsySuck]

Also in eventlog a lot of these errors: MailSlot Client Write Error (MGT) :The system cannot find the file specified All new users are affected.

for this problem, which in no way interferes with operations for users, it is simply notifications between ADFS servers. Restart the Windows service "MFA notification Hub" or in PowerShell "restart-service mfanotifhub" on the server concerned.

regards

[PsySuck]

Can i downgrade safely to previous release?

I think you can do it with no worries. But, your problem will not have disappeared (see above)

[PsySuck]

I don't understand. All new users cannot register. If you look at the logs, MFATOTPKEY changes three times during registration.

What is the problem now:

• if you delete a user, he will be shown qr - then he will be able to log in and receive a message about successful registration.
• At the same time, there is a completely different code in the console.

I checked "Solution" from https://github.com/neos-sdi/adfsmfa/issues/98 it is not helped.

[redhook62]

Hi, @PsySuck

I'm lost myself, and don't know where you are.

Have you repositioned the hash in SHA512? If this is the case, all users registered for more than 10 Days (before the changes you made), should connect without problems. For users registered for 10 days (after the changes you made), the key is invalid, these users must scan a new key again or create a new key (Console/User/New Key or Console/User/Delete Key and let the user renew via the UX its key).

Then to check if there is a bug as indicate. In the console, for a given test user. generate a new key, scan that key on the screen, then test a connection. Then, with the same user, generate a new key and send it by email (email required), scan the QR code and test a new connection.

Tell me precisely the results, knowing that on my side all this is functional.

regards

[PsySuck]

I changed settings from sha256 to sha1 because google authenticator does not work correctly some times. Yes some users have problem - we reenrolled all otp. Now:

• I removed user: `Get-MFAUsers *****@**.com | remove-mfausers

Confirm Are you sure you want to perform this action? Performing the operation "Remove-MFAUsers" on target ""*****@**.com"". [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): y`

• I register new TOTP im my applications and successfully login:

  

• I perfom sign out and OTP not working anymore.

• I can't send QR via email because this error: Error Sending Email (KEY) for user ...: Input string was not in a correct format

• I open mmc i scan QR: Now it working.

[redhook62]

Hi @PsySuck

I for my part redid all the tests that I had asked you. I had no problem.

My configuration is: RSA / SHA512 / 6 digits / 30s Apps Used Microsoft Authenticator: SHA1 Google Authenticator: SHA1 Aegis Authenticator: SHA512

Each time the same QR Code scanned by the 3 applications, For Microsoft and Google, the code is similar on the 2 applications For Aegis, the code is different because the QR Code is in SHA512.

And of course, I managed to identify myself with each of the 3 applications, with SHA1 (MS, Google), and SHA512 (Aegis). This is the expected behavior, and as I told you, this part hasn't changed for 4 years. I also managed to send the emails and this in several languages

I am attaching a new build, in which I have just corrected the "Delete Key" button in the console which was not operational.

Perhaps you could update the authentication applications, and perhaps even the operating systems. also check that the time is in sync.

Thank you in advance for your return.

regards adfsmfa 3.1.2204.999.msi.zip

[PsySuck]

I checked Active Directory audit logs for past mouth. Sometimes during registration MFA-TOTP-Key and MFA-RSA-Certificate were update 2-3 times. Is it expected behaviour? Also sometime mmc print this error to eventlog: Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index

[redhook62]

Yes, for registration it is normal operation. once upon presentation of the QR Code, and once after validation.

For printing from the console, have you implemented modified mail templates? I have no explanation, what do you mean by sometime? is it related to a specific user? or completely random ? Do you only use TOTP (no emails, no biometrics) ?

[PsySuck]

Completely random. I found users with 1-3 modifications during registration.

On Thu, 7 Apr 2022 at 10:40, redhook @.***> wrote:

Yes, for registration it is normal operation. once upon presentation of the QR Code, and once after validation.

For printing from the console, have you implemented modified mail templates? I have no explanation, what do you mean by sometime? is it related to a specific user? or completely random ? Do you only use TOTP (no emails, no biometrics) ?

— Reply to this email directly, view it on GitHub https://github.com/neos-sdi/adfsmfa/issues/224#issuecomment-1091203200, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUX63WBUZMXKTMBFM55EXW3VD2GN5ANCNFSM5SURISTA . You are receiving this because you were mentioned.Message ID: @.***>

[redhook62]

the explanation that I can submit to you is that either the user gave up after presenting the QR Code (1 time), or he validated his registration (2 times), or he restarted his scan because the validation n didn't work (3 and more times)

Are you using only TOTP?

regards

[PsySuck]

Yes. Currently only TOTP.

On Thu, 7 Apr 2022 at 11:16, redhook @.***> wrote:

the explanation that I can submit to you is that either the user gave up after presenting the QR Code (1 time), or he validated his registration (2 times), or he restarted his scan because the validation n didn't work (3 and more times)

Are you using only TOTP?

regards

— Reply to this email directly, view it on GitHub https://github.com/neos-sdi/adfsmfa/issues/224#issuecomment-1091274495, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUX63WHEYEX5V6IPUC53WBTVD2KVNANCNFSM5SURISTA . You are receiving this because you were mentioned.Message ID: @.***>

[PsySuck]

Thanks, i fixed mail, wrong folder. I received in message:

I decoded QR: otpauth://totp/-SSO:**%40.com?secret=J7E3Z74GMGEKUBTNLRVEMWJJH7HBOKDZORF6GB6TM73JHVXNBPCNBEZLSWQYTSZCLEEI3IVGSSPX27SUCIDBSE7SR3I3SAHIMGCCNZZFLGMMAWOQ3OUKEHRNXYWCQKGFFQ7KFXJ2NFV5B4MIJ4LS2LY4WW2CQRAA5EGDR2RYQG4T4E5W4AUKGIOH5LRBDAP5UFCCK36RGBER4&issuer=-SSO&algorithm=SHA1&digits=6&period=30

valid secret - J7E3Z74GMGEKUBTNLRVEMWJJH7HBOKDZORF6GB6TM73JHVXNBPCNBEZLSWQYTSZCLEEI3IVGSSPX27SUCIDBSE7SR3I3SAHIMGCCNZZFLGMMAWOQ3OUKEHRNXYWCQKGFFQ7KFXJ2NFV5B4MIJ4LS2LY4WW2CQRAA5EGDR2RYQG4T4E5W4AUKGIOH5LRBDAP5UFCCK36RGBER4

[PsySuck]

Here is examples:

I delete my user. I register new OTP. I scan my QR from mmc. Accounts name are different too

[redhook62]

Listen, I don't know. I cannot reproduce your problem. Everything works perfectly for me on different configurations, and with customers.

[PsySuck]

Listen, I don't know. I cannot reproduce your problem. Everything works perfectly for me on different configurations, and with customers.

I understand that you can't reproduce it. maybe you can do a debug build with event logging and a key in the eventlog, or share out pdb for build 3.1.2204.999 so that I can debug it myself?

[redhook62]

Hi,

I just redid a test to check that the QRCode displayed in the UX during registration corresponds to the QRCode that will be displayed in the admin console.

Also checked the QRCode sent by email, and finally checked the QRCode after printing. and I also redid all these tests with RSA 1024 bits.

There is therefore no worries on this side, debugging would surely be useless. version 2204.0 is not in question.

There is therefore a particularity with you, either at the level of systems, client devices (telephones and authentication applications), or MFA parameters (which for the TOTP part now seem correct).

The key you decoded is truncated, normal you chose 1024 bits. however the issuer doesn't seem correct, it's specified in 2 places normally, I don't know if your value is correct.

regards

[PsySuck]

You have done an excellent job. I tested ADFSMFA for almost 8 months and had no problems. But now they are. The QR code that is shown to the user is different from what is recorded in the storage. There seems to be some external factor that made it more important, as only a small part of the users had the problem - now the majority, so I could not reproduce the problem before. But it is interesting that if the user was imported and he logs in in an alternative way and registers TOTP, then everything will work. The problem is most likely unique to the environment. This is reason why i asking about pdb.

I also found that the number of users returned by get-mfausers changed from 1500+ to 1024.

[redhook62]

Hi, @PsySuck

Okay, today i will send to you the latest build with the pdb. because I don't keep the .pdb's between each build. The source code is available and you can do your own build anytime, @apr-un has documented the process here: Build

Tthe key that is stored is very different from the one that is used to generate the QRCode in general and is decrypted. this is normal, this key cannot be reused or copied to another user.

On the encrypted (stored) key 1) - A XOR operation with the PassPhrase of your config 2) - Using the certificate assigned to the user (pfx) 3) - Access to the private key via a password made with the checksum of the user's name 4) - Decryption operation (Asynchronous) with the private key 5) - Verification of the name of the user present somewhere in the key. 6) - key passed to the TOTP algo (time period application, hash (SHA1, SHAxxx), BASE10 conversion. 7) - Creation of the uri: authotp://totp/....

Try typing @Get-MFAUsers -IncludeDisabled to get all users

regards

[PsySuck]

Thank you for explanation! I hope i will able to find root cause.

[redhook62]

Hi,

latest sources with .pdb

specialbuild.zip

regards

[apr-un]

Hi @PsySuck

Remember that building Your version can cause some "disturbances" in configuration, because You'll have another public key (signature) which is used to encrypt/decrypt some data from configuration. Safest bet is to export adfs configuration (backup), unregister Neos MFA, uninstall Neos MFA, install MFA with Your signature, register Yours MFA set all needed password/pins by MFA security cmdlet

In worst case application doesn't work because configuration problems (check logs), in that case try to manually edit exported configuration xml and then reimport it again

@redhook62 Today we did some more tests with my custom adapter on version 2204.0 and I can confirm that there is some kind of problem with QR code/TOTP. During registration of new user QR code is scanned and "works", but during logging in as this user TOTP says that its invalid code. Scanning code from MFA console application generate other code than during registration. I cannot debug it now, but I'll try it later

PS: When I installed 2204.0 I also saw errors about MailSlot Client Write Error (MGT) :The system cannot find the file specified but after two days of 'changing' configuration these errors are gone now (don't know why). Also when I had problems with configuration I often see errors about contacting net.tcp://localhost:5987 - is this a part of MFA? These error are also gone now... Error Initializing WebAuthN Metdata Repository : There was no endpoint listening at net.tcp://localhost:5987/WebAdminService that could accept the message. This is often caused by an incorrect address or SOAP action.

Regards apr-un

[PsySuck]

@apr-un thank for you respond. I will try downgrade to older version on dev stand and find working version.

[apr-un]

@PsySuck I think that downgrading is genarally ok (we did it many times), just don't go lower than version 2201 - there were changes that are written in adfs db (enums were renamed) and that caused problems with configuration deserialization :)

[PsySuck]

@redhook62 thank you! I can confirm you fixed this.