Directory Sync Pro 20.11.4 can be successfully deployed in a FIPS environment by following the procedure described in this document.
The audience for this section is technical implementation consultants deploying Directory Sync Pro.
Directory Sync Pro relies on the following Third-Party cryptographic libraries for its cryptographic needs.
|
Cryptographic usage |
Cryptographic algorithm |
Cryptographic parameters |
|---|---|---|
|
Communication – Website User Interface |
SSL TLS 1.2 or higher |
|
|
Communication – (SMB 3.x) |
AES-128-CMAC, AES-128-GCM |
|
|
Communication – (SMB 2.1) |
HMAC-SHA256 |
|
|
Communication – (LDAP/Kerberos) |
AES128_HMAC_SHA1, AES256_HMAC_SHA1 |
SESSION: Signing & Sealing |
|
Communication – (Kerberos NTLM Authentication) |
RC4_HMAC_MD5 |
|
|
Symmetric encryption of bulk data |
AES256 CBC Mode |
KEY: 256-bit PBKDF2 (Constant) IV: 128-bit PBKDF2 (Constant) |
|
Symmetric encryption of bulk data – Additional Entropy |
RNG |
64-bits (Random per encrypted value) |
|
Symmetric encryption of secrets – (DPAPI) Configuration Parameters |
AES256 CBC Mode |
SCOPE: LocalMachine |
|
Symmetric encryption of secrets – Additional Entropy |
RNG |
256-bits (Constant per node) |
|
Hashing – (PBKDF2) Generation of encryption KEY/IV |
HMACSHA1 |
HASH SIZE: 160-bit |
|
Hashing – (DPAPI) |
SHA512 |
HASH SIZE: 523-bit |
|
Hashing – Attribute Change Detection |
SHA256 |
HASH SIZE: 256-bit |
|
Hashing – Legacy Attribute Change Detection |
MD5 |
HASH SIZE: 128-bit |
To execute in a FIPS compliant mode, a Windows environment requires the Microsoft Policy “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing” setting enabled.
Microsoft states that “This policy is only advisory to applications. Therefore, if you enable the policy, it does not make sure that all applications will comply”.
Directory Sync Pro leverages Microsoft’s CryptoAPI (CAPI) and CryptoAPI Next Generation (CNG) for its cryptographic needs.
Microsoft Product Relationship with CNG and CAPI libraries is documented here: https://technet.microsoft.com/en-us/library/cc750357.aspx
“Rather than validate individual components and products, Microsoft chooses to validate only the underlying cryptographic modules. Subsequently, many Windows components and Microsoft products are built to rely on the Cryptographic API: Next Generation (CNG) and legacy Cryptographic API (CAPI) FIPS 140 validated cryptographic modules. Windows components and Microsoft products use the documented application programming interfaces (APIs) for each of the modules to access various cryptographic services.
