FIPS Error with Active Directory Explorer

[brupnick]

Good afternoon-

While working with support on an issue with ADE, I looked in the log file immediately after loading ADE and saw the following:

Code: Select all

Error: This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.

I know that this was an issue with the Other OS FLR way back in v6.1 (http://forums.veeam.com/veeam-backup-re ... 14161.html) and am surprised to still be running across this is version 8. As per Microsoft's hardening recommendations, the "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" GPO setting is enabled on my Server 2012 R2 box.

Is there a way to fix this other than to disable the GPO setting? And yes, after changing that GPO to "Disabled" and rebooting, the FIPS error is gone and ADE loads successfully.

[tsightler]

This may simply mean that opening Active Directory requires the use of .NET cryptographic functions that are not FIPS compliant. Whether a particular implmentation of an algorithm is FIPS doesn't really mean much from a security perspective and even Microsoft has changed it's guidance regarding FIPS mode for anyone that doesn't have to meet a federal mandate to use it. The article below is a good read:

http://blogs.technet.com/b/secguide/arc ... ymore.aspx

Basically, you can write a brand new application using the latest secure hashing algorithms and the latest crypto, but if you use the .NET version, which Microsoft hasn't submitted for FIPS certification, .NET will block it with this message. That doesn't mean the application is insecure in any way, and ever worse, it certainly doesn't guarantee that it is secure (an application is free to implement it's own crappy implementation of any weak cipher it likes even with FIPS mode enabled in the OS).

Of course this doesn't really help you if you are mandated to use FIPS compliance mode, but just wanted to point out why even brand new code might still run up against messages like this.

[brupnick]

Tom, as always, you are a wealth of helpful information. In my particular instance, our security team has signed off on a hardened server that has this setting enabled. I'm sure that with the right justification, I can disable it, but I wanted to see if there was another solution that wouldn't require me to do that. As I mentioned in my original post, I've been seeing these FIPS errors in one part of VBR or another since 6.1. Does Veeam do any testing with this setting enabled? Even if it's not something that you, Veeam, could fix, at least it could be included in the Known Issues documentation.

I would also like to point out that this came to my attention when I realized that ADE wasn't working as expected. It would seem to mount fine, but when I would select my ntds.dit, I got an error that read:

Code: Select all

The process cannot access the file '<path to ntds.dit>' because it is being used by another process.

This led me to the ADE log for that session which had the FIPS error at the bottom. So if anyone else receives this error message, it's possible that it might not have anything to do with access to the ntds.dit file.

[tsightler]

It's a good question about testing with this option enabled. I'm going to guess that there's not any specific testing, although perhaps core functions are tested and AD Explorer was just a corner case that was missed. I certainly run across this issue as well since I sometimes work with US federal and financial services clients where this OS setting is mandated and getting exceptions for this can be difficult so I'm hopeful we can overcome it.

[Gostev]

Error: This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.

So apparently what causes VEAD to trigger this error is the fact that Microsoft considers MD5 hash function to not be FIPS-compliant. However, at the same time they are using this very function in Active Directory to hash account passwords... go figure!

[brupnick]

For anyone that might be interested, this issue has been resolved in patch #1 for version 8. Thanks for listening, Veeam!!