Configuring AD LDS Password Hash Algorithm

Hello,
I have a client which has a requirement that the passwords in Active Directory should be stored using the Secure Hash Standard (SHS) standard. This could be SHA-1 or SHA-2.
Could you please tell me where can I check the current hashing algorithm and configure the new one?
Windows Server 2008 R2 Enterprise
Forest & Domain functional level: Windows Server 2008 R2
Thanks!

Hi Levente,
I don’t think it is possible to specify algorithm to encrypt AD passwords. The password is computed by RSA MD-4 and MD-5 algorithm.
More information for you:
Help: How to configure encryption/hashing policies on Active Directory 2008 LDS
http://social.technet.microsoft.com/Forums/windowsserver/en-US/04591e6e-22d3-4251-ab55-b778a479465e/help-how-to-configure-encryptionhashing-policies-on-active-directory-2008-lds?forum=winserverDS
View Password hash in Active Directory
http://social.technet.microsoft.com/Forums/windowsserver/en-US/63e3cf2d-f186-418e-bc85-58bdc1861aae/view-password-hash-in-active-directory?forum=winserverfiles
Active Directory hashing algorithms used?
http://social.technet.microsoft.com/forums/windowsserver/en-US/7fbc0669-2ccb-4c24-9f08-24241e30d72b/active-directory-hashing-algorithms-used
Md5 passwords in Active Directory
http://social.technet.microsoft.com/Forums/windowsserver/en-US/5bed809e-3e04-4917-b940-47d3c758987f/md5-passwords-in-active-directory
Best Regards,
Amy

Similar Messages

OID And Java Hash Algorithm Output Differences?

Hi,
Can anyone tell me why I am not able to recreate the OID ldap password hash algorithm? Or can anyone tell me why I get these subtle differences between my Java created message digest and the one that is read directly from the oracle ldap hint password field? They are both based on the same original word "test".
OID Hint Password from ldap ==> {SHA}zrFqbho8VPUOnVvtyUb4c+RWF+k=
Hash created based on input ==> {SHA}zrFqbho8VPUOP1vtyUb4c+RWF+k=
Here is a little background. I am working on developing a custom forgot password feature for my web site using OID 10g R2 and Java. I am able to retrieve the oracle hint password from OID using Java JNDI as the orcladmin. This ldap password is a SHA message digest, or hash, that is base 64 encoded. Since it is a one way algorithm I can not decrypt. So instead I take the clear text password string provided by the user and create a message digest(SHA) and then encode in base 64 using Java 1.4.2 like so;
MessageDigest md = MessageDigest.getInstance("SHA");
md.update(clearTextPassword.getBytes());
String userSuppliedPassword = new String(md.digest());
BASE64Encoder base64encoder = new BASE64Encoder();
String output = "{SHA}" + base64encoder.encode(userSuppliedPassword.getBytes());
By the way, I have been able to work around this issue by performing the compare using JNDI search but was curious why this was happening. Thanks!

Hi
I am having similar issue. I have to save passwords in encrypted form to LDAP. But not working. I am prepending the encrypted password {SHA} so OID should not convert further.
Any help is appreciated
Thanks

Hash algorithms for passwords.

Hello!
I have those question.
When I store password in database I can use any hash algorithms.
But if I would use local database and start my application on another computer values after hashing will be the same or not?
For example :
string password = "admin";
int passwordToDb = password.GetHashCode(); // this value I save in db.
On another computer, when I will verify my password and calculate hash, it wouldn't be the same? I guess that not.
And what about SHA algorithms? Will I have such problem?

Use MD5 encryption :
/// <summary>
/// Hasher la chaîne en MD5
/// </summary>
/// <param name="chaine">La chaîne à hasher.</param>
/// <returns>La chaîne hashée.</returns>
public static String hashWithMD5(String chaine)
//L'objet MD5.
MD5 md5HashAlgo = MD5.Create();
//le résultat.
StringBuilder resultat = new StringBuilder();
//Tableau d'octes pour le hashage.
byte[] byteArrayToHash = Encoding.UTF8.GetBytes(chaine);
//Hasher la chaîne puis placer le résultat dans le tableau.
byte[] hashResult = md5HashAlgo.ComputeHash(byteArrayToHash);
//Parcourir le tableau pour le mettre dans le résultat.
for (int i = 0; i < hashResult.Length; i++)
//Afficher le Hash en hexadecimal.
resultat.Append(hashResult[i].ToString("X2"));
//Retourner le résultat.
return resultat.ToString();

Is it possible to change the hash algorithm when I renew the Root CA

My Root CA is installed on a Windows Server 2008. The Hash algorithm of Root CA in my environment is MD5. I would like to renew the Root CA and change the Hash algorithm to SHA1. Is it possible to change it?
Regards,
Terry | My Blog: http://terrytlslau.tls1.cc

Hi,
The hashing
algorithm chosen during the setup of a Certificate Authority determines how the certificates that the CA issues are digitally signed. It is a one
algorithm per CA scenario, so if your environment requires multiple algorithms for compatibility, then you will need multiple PKI hierarchies (one for each
algorithm.) Prior to Windows 2008, you had to rebuild the CA and decommision the entire PKI hierarchy to
change the signing algorithm used. In Windows 2008 and 2008 R2, we allow you to
change the algorithm and from that point forward it will digitally sign all new certificates with the updated
algorithm.
The
Certificate
Services Enhancements in Longhorn Server Whitepaper describing these steps can be found under the section
Configuring the Cryptographic Algorithms used by the CA.
Step 1: Verify the configuration of the CRL and AIA paths. Sometimes users will manually
change these paths to not include the crl name suffix variable that distinguish multiple certificates on a CA. This is important because the process of changing the
algorithm requires the renewal of the private key and results in administration of multiple CA certificates. When we publish multiple crt and crls, they will be identified as CAName and CAName(1.) You can verify these paths
include the variables by checking the registry keys below:
[HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\{CAname}
CRLPublicationURLs = "1:%WINDIR%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n2:http://FCCA01.fourthcoffee.com/certenroll/%%3%%8%%9.crl\n10:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public
Key Services,CN=Services,%%6%%10"
CACertPublicationURLs = "1:%WINDIR%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:http://FCCA01.fourthcoffee.com/certenroll/%%1_%%3%%4.crt\n2:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11"
Step 2: Modify the CSP parameters to specify the new
algorithm. The CSP may use the original CryptoAPI or Cryptography API:Next Generation - you can verify this by looking in the registry key
HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\{CAname}\CSP.
If you have the regvalues
CNGPublicKeyAlgorithm and CNGHashAlgorithm then your CSP is using Next Generation.
Change the
algorithm from MD5 to SHA1 and was using Cryptography API: Next Generation. The original registry value was:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\CertSvc\Configuration\{CAname}\CSP]
"ProviderType"=dword:00000000
"Provider"="Microsoft Software Key Storage Provider"
"HashAlgorithm"=dword:00008003
"CNGPublicKeyAlgorithm"="RSA"
"CNGHashAlgorithm"="MD5"
"MachineKeyset"=dword:00000001
we changed it to
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\CertSvc\Configuration\{CAname}\CSP]
"ProviderType"=dword:00000000
"Provider"="Microsoft Software Key Storage Provider"
"HashAlgorithm"=dword:00008004
"CNGPublicKeyAlgorithm"="RSA"
"CNGHashAlgorithm"="SHA1"
"MachineKeyset"=dword:00000001
Step 3: Restart the CA service. You can do this in the CA MMC. Right Click on the
CA and choose "Stop Service" and "Start Service".
Step 4: Renew the CA certificate with new Private Key. Right click on the CA and
choose "Renew CA certificate". Choose to renew the public and private key pair. On completion, this will result in the CA having two certificates. You will see that the old one has the MD5 for the Signature
Hash Algorithm and that the new certificate uses SHA1.
Hope this helps!
Best Regards
Elytis Cheng
TechNet Subscriber Support
If you are
TechNet Subscription
user and have any feedback on our support quality, please send your feedback
here.
Elytis Cheng
TechNet Community Support

View Password hash in Active Directory

Hi all
I am the administrator and i want to view the password hashes of the users in Active Directory. Please tell me how i can view the password hashes of the users. Where are the password hashes of the users stored in Active Directory.

Hi,
Before going further, let’s clarify how Windows store password.
Instead of storing the user account password in clear-text, Windows generates and stores user account passwords by using two different password representations, generally known as "hashes." When you set or change the password for a user account to a password that contains fewer than 15 characters, Windows generates both a LAN Manager hash (LM hash) and a Windows NT hash (NT hash) of the password. These hashes are stored in the local Security Accounts Manager (SAM) database (C:\Windows\System32\config\SAM file) or in Active Directory (C:\Windows\NTDS\ntds.dit file on DCs).
You can force Windows to use NT Hash password. For detailed information, please refer to the following article.
How to prevent Windows from storing a LAN manager hash of your password in Active Directory and local SAM databases
http://support.microsoft.com/kb/299656
After you configure Password History, Active Directory service will check the password hash stored in AD database to determine if user meet the requirement. Administrator doesn’t need to view or use password hash.
Regarding the security of password, the following article may be helpful.
Should you worry about password cracking?
http://blogs.technet.com/jesper_johansson/archive/2005/10/13/410470.aspx
Hope this information can be helpful.
This posting is provided "AS IS" with no warranties, and confers no rights.

ACE20 and hashing algorithm

I have a secure website behind an Cisco ACE20 using A2(3.2). Everything is working great. Only that now I need to renew my certificate. When creating the CSR and sending it to my CA I get this warning:
"Alert: Your CSR has been signed using the MD5 hashing algorithm. While the MD5 hashing algorithm is not optimal it will not prevent you from using this CSR to enroll for your SSL certificate. VeriSign best practices recommend that you use a different hashing algorithm for the signature. CSR Information"
Anybody know if it is possible to use SHA instead of MD5 or what can I do in this case?

I dont think you can chnage the signing method for CSRs on the ACE directly. But i would use something like OpenSSL to generate the CSR for SHA.
http://gnuwin32.sourceforge.net/packages/openssl.htm
openssl req -out c:\CSR.csr -new -newkey rsa:2048 -nodes -keyout c:\privateKey.key -sha1
The above will load a wizard format questionare for your CSR parameters similar to the ACE.
You can then upload your key, and cert when you get it to the ACE afterwards.
==========================
http://www.rConfig.com
A free, open source network device configuration management tool, customizable to your needs!
- Always vote on an answer if you found it helpful

Which SHA hash algorithm is DS 5.1 using?

i'm trying to find out whether DS 5.1 uses the SHA-1 (160 bit) or the SHA-256 (256bit). i'm using coldfusion to query the directory and in order to compare password given by the user with the one stored in the directory i should hash the given password. coldfusion (a library, it's not a default function) has two differnt hash algorithms SHA-1 and SHA-256, which one should i use?
ioanna

DS uses SHA-1 (160 bit). And I'm not sure what you are proposing will work. I think you need the salt to generate the hash. Why do you need to compare the password outside the directory? You might be able to use the LDAP compare operation.

What's type of ACS v4.2 Database password hash?

What's type of ACS v4.2 Database password hash?
example:
Name          :          ###postureuser
Password      :          0x0020 fe fc f0 11 24 dc dd bd 0f d9 78 56 b8 4a fc f4 40 d0 bd 1d 19 5b 56 7e 14 f0 4e 1a b0 83 66 24
Chap password :          0x000e 22 07 e4 28 c0 09 7f 1a b7 e6 2a 78 a1 52
Thanks!

Hello,
I have been looking for an answer on this query, however, I have not been able to find the exact answer. I did find some useful information which I will include below:
1) Using "csutil -d" you will be able to extract both Usernames and Passwords from the ACS Internal Database. Usernames will be on clear text and the password will be hashed with the specified password you used when executing
"csutil -d".
C:\Program Files\CiscoSecure ACS v4.2\bin>CSUtil.exe -d
CSUtil v4.2(0.124), Copyright 1997-2008, Cisco Systems Inc
Please, provide secret key to encrypt user passwords being dumped.
This key will be asked during dump file importing.
Empty Passwords will create dumps which are not re-loadable into ACS..
2) It seems that the hash has not been revealed by Cisco ACS Developers. However, they have confirmed that the User Passwords are hashed using that password. Also, if using an "empty" password the exported user passwords will be "cisco123" or hashed: 0x0008 63 69 73 63 6f 31 32 33
If you are trying to convert the passwords to clear text in order to recreate the accounts on a different server other than ACS (AD, LDAP, 3rd Party RADIUS) it will not work as there are not any known procedures to decrypt those passwords.
Deeper investigation can be requested to TAC, however, I am not sure how accessible would it be to have a Developer share the hash method/algorithm used for Password encryption on the ACS Internal Database as it might be considered a security breach on the database of the application.
Hope this clarifies it.
Regards.

Linux Redhat RHAS 2.1 & 3.x /etc/shadow hash algorithm

We are trying to load the linux user passwords into our OID server.
The hash is not unix crypt.
We have other unix like the HPUX server's work fine as {CRYPT} but the linux shadow does not migrate.
What is the default hash algorithm for RH?
Has anybody done users & passwords from RH -to-> OID?

That's what we all remember too. But it doesnt.
HPUX uses {CRYPT} syncs fine with OID userPassword field.
That same password value doesn't match with Linux.
So we tried {MD5} format. no luck.
I've created the user rp9999 rp9999 on several Linux systems. differnet value each time:
i tried this on my linux machine:
useradd rp9999 rp9999
passwd rp9999 (type password wrong twice: rp9999 rp9999)
/etc/shadow
rp9999:$1$YkjrvM53$gIyxjK8fLFuCmPjywPPXz/:13024:0:99999:7:::
Linux mach1 2.4.21-27.0.2.EL #1 Wed Jan 12 23:46:37 EST 2005 i686 i686 i386 GNU/Linux
so i went to a different machine - mach2:
rp9999:$1$d.DdubGw$Gqj.LxU8Fejq5yNFMSphC1:13024:0:99999:7:::
but from seperate DIFFERENT oid servers user=rp9999 & oidpasswd=rp9999:
authpassword;orclcommonpwd={MD5}XxXV8b0izcJsmcQJ23lmoQ==
userpassword: {MD5}XxXV8b0izcJsmcQJ23lmoQ==
What's going on with Linux /etc/shadow?

HTTPS SSL Certificate Signed using Weak Hashing Algorithm

I am support one client for, whom falls under Security scans mandatory for new implementation of ASA 5520 device . The client uses Nessus Scan and the test results are attached
The Nessus scanner hit on 1 Medium vulnerabilities, Could you pls review the statement and provide work around for the same.
Nessus Scanner reports
Medium Severity Vulnerability
Port : https (443/tcp)
Issue:
SSL Certificate Signed using Weak Hashing Algorithm
Synopsis :
The SSL certificate has been signed using a weak hash algorithm.
Description :
The remote service uses an SSL certificate that has been signed using
a cryptographically weak hashing algorithm - MD2, MD4, or MD5. These
signature algorithms are known to be vulnerable to collision attacks.
In theory, a determined attacker may be able to leverage this weakness
to generate another certificate with the same digital signature, which
could allow him to masquerade as the affected service.
See also :
http://tools.ietf.org/html/rfc3279
http://www.phreedom.org/research/rogue-ca/
http://www.microsoft.com/technet/security/advisory/961509.mspx
http://www.kb.cert.org/vuls/id/836068
Solution :
Contact the Certificate Authority to have the certificate reissued.
Plugin Output :
Here is the service's SSL certificate :
Subject Name:
Common Name: xxxxxxxxxx
Issuer Name:
Common Name: xxxxxxxxxx
Serial Number: D8 2E 56 4E
Version: 3
Signature Algorithm: MD5 With RSA Encryption
Not Valid Before: Aug 25 11:15:36 2011 GMT
Not Valid After: Aug 22 11:15:36 2021 GMT
Public Key Info:
Algorithm: RSA Encryption
Public Key: 00 AA AB 57 9C 74 FF E9 FB 68 E1 BF 69 90 8E D2 65 7F DF 40
D6 F6 29 E7 35 5E 16 FB 76 AA 03 3F 47 07 5A D0 6D 07 E0 EC
06 7E D4 9A 43 C6 B3 A6 93 B7 76 CC 58 31 25 36 98 04 30 E6
77 56 D7 C3 EE EF 7A 79 21 5E A0 78 9B F6 1B C5 E6 2A 10 B5
CB 90 3D 6D 7C A0 8D B1 B8 76 61 7F E2 D1 00 45 E2 A1 C7 9F
57 00 37 60 27 E1 56 2A 83 F5 0E 48 36 CC 61 85 59 54 0C CB
78 82 FB 50 17 CB 7D CD 15
Exponent: 01 00 01
Signature: 00 24 51 24 25 47 62 30 73 95 37 C4 71 7E BD E4 95 68 76 35
2E AF 2B 4A 23 EE 15 AF E9 09 93 3F 02 BB F8 45 00 A1 12 A9
F7 5A 0C E8 4D DB AE 92 70 E4 4C 24 10 58 6B A9 87 E1 F0 12
AE 12 18 E8 AB DF B9 02 F7 DA BE 3C 45 02 C4 1E 81 44 C2 74
25 A2 81 E7 D6 38 ED B9 66 4C 4A 17 AC E3 05 1A 01 14 88 23
E8 9F 3B 5C C5 B8 13 97 27 17 C3 02 5F 6E 7C DB 4C D3 65 B5
C5 FC 94 62 59 04 E7 7E FB
CVE :
CVE-2004-2761
BID :
BID 11849
BID 33065
Other References :
OSVDB:45106
OSVDB:45108
OSVDB:45127
CWE:310
Nessus Plugin ID :
35291
VulnDB ID:
69469
and try with configure the ssl encryption method with " ssl encryption 3des-sha1 aes128-sha1 aes256-sha1 rc4-md5" but it throws the same issue.
Here is ASA log
7|Oct 19 2011 01:59:34|725010: Device supports the following 4 cipher(s).
7|Oct 19 2011 01:59:34|725011: Cipher[1] : DES-CBC3-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[2] : AES128-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[3] : AES256-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[4] : RC4-MD5
7|Oct 19 2011 01:59:34|725008: SSL client production:xxxxxxxxx/2587 proposes the following 26 cipher(s).
7|Oct 19 2011 01:59:34|725011: Cipher[1] : ADH-AES256-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[2] : DHE-RSA-AES256-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[3] : DHE-DSS-AES256-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[4] : AES256-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[5] : ADH-AES128-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[6] : DHE-RSA-AES128-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[7] : DHE-DSS-AES128-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[8] : AES128-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[9] : ADH-DES-CBC3-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[10] : ADH-DES-CBC-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[11] : EXP-ADH-DES-CBC-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[12] : ADH-RC4-MD5
7|Oct 19 2011 01:59:34|725011: Cipher[13] : EXP-ADH-RC4-MD5
7|Oct 19 2011 01:59:34|725011: Cipher[14] : EDH-RSA-DES-CBC3-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[15] : EDH-RSA-DES-CBC-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[16] : EXP-EDH-RSA-DES-CBC-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[17] : EDH-DSS-DES-CBC3-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[18] : EDH-DSS-DES-CBC-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[19] : EXP-EDH-DSS-DES-CBC-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[20] : DES-CBC3-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[21] : DES-CBC-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[22] : EXP-DES-CBC-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[23] : EXP-RC2-CBC-MD5
7|Oct 19 2011 01:59:34|725011: Cipher[24] : RC4-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[25] : RC4-MD5
7|Oct 19 2011 01:59:34|725011: Cipher[26] : EXP-RC4-MD5
7|Oct 19 2011 01:59:34|725012: Device chooses cipher : DES-CBC3-SHA for the SSL session with client production:xxxxxxxx/2586
6|Oct 19 2011 01:59:34|725002: Device completed SSL handshake with client production:xxxxxxxxx/2586
6|Oct 19 2011 01:59:34|725007: SSL session with client production:xxxxxxxx/2586 terminated.
6|Oct 19 2011 01:59:34|302014: Teardown TCP connection 3201 for production:xxxxxxx/2586 to identity:xxxxxx/443 duration 0:00:00 bytes 758 TCP Reset-I
6|Oct 19 2011 01:59:34|302013: Built inbound TCP connection 3202 for production:xxxxxxxxxxx/2587 (xxxxxxxxx/2587) to identity:xxxxxx/443 (xxxxxxx/443)
6|Oct 19 2011 01:59:34|725001: Starting SSL handshake with client production:xxxxxxxxxxx/2587 for TLSv1 session.
7|Oct 19 2011 01:59:34|725010: Device supports the following 4 cipher(s).
7|Oct 19 2011 01:59:34|725011: Cipher[1] : DES-CBC3-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[2] : AES128-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[3] : AES256-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[4] : RC4-MD5
7|Oct 19 2011 01:59:34|725008: SSL client production:xxxxxxxxx/2587 proposes the following 26 cipher(s).
7|Oct 19 2011 01:59:34|725011: Cipher[1] : ADH-AES256-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[2] : DHE-RSA-AES256-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[3] : DHE-DSS-AES256-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[4] : AES256-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[5] : ADH-AES128-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[6] : DHE-RSA-AES128-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[7] : DHE-DSS-AES128-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[8] : AES128-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[9] : ADH-DES-CBC3-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[10] : ADH-DES-CBC-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[11] : EXP-ADH-DES-CBC-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[12] : ADH-RC4-MD5
7|Oct 19 2011 01:59:34|725011: Cipher[13] : EXP-ADH-RC4-MD5
7|Oct 19 2011 01:59:34|725011: Cipher[14] : EDH-RSA-DES-CBC3-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[15] : EDH-RSA-DES-CBC-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[16] : EXP-EDH-RSA-DES-CBC-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[17] : EDH-DSS-DES-CBC3-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[18] : EDH-DSS-DES-CBC-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[19] : EXP-EDH-DSS-DES-CBC-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[20] : DES-CBC3-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[21] : DES-CBC-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[22] : EXP-DES-CBC-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[23] : EXP-RC2-CBC-MD5
7|Oct 19 2011 01:59:34|725011: Cipher[24] : RC4-SHA
7|Oct 19 2011 01:59:34|725011: Cipher[25] : RC4-MD5
7|Oct 19 2011 01:59:34|725011: Cipher[26] : EXP-RC4-MD5
7|Oct 19 2011 01:59:34|725012: Device chooses cipher : DES-CBC3-SHA for the SSL session with client production:xxxxxxxxxx/2587
6|Oct 19 2011 01:59:34|725002: Device completed SSL handshake with client production:xxxxxxxxx/2587
H

Hi Ramkumar,
The report is complaining that the Certificate Authority who signed the ID certificate presented by the ASA used a weak hashing algorithm. First, you need to determine who signed the certificate.
If the certificate is self-signed by the ASA, you can generate a new certificate and use SHA1 as the hashing algorithm. To do this, the ASA needs to be running a software version that is at least 8.2(4) (8.3 and 8.4 software also support SHA1).
If the certificate is signed by an external CA, you need to contact them and ask them to sign a new certificate for you using SHA instead of MD5.
The links you posted have more information on this as well. Hope that helps.
-Mike

T61p - Please wait while Windows configures Client Security Password - Manager

My T61p system is fully updated, however I continue to get "Please with while windows configures Client Security Password - Manager." and then the computer trys to install
css_manager_vista_tpm.exe
over and over again.
What is the problem here and how can I solve?
How can I contact Lenovo-Thinkpad to assist?
The problem has reoccured even after I did a system restore to an earlier date.
It seems to initiate when I first boot up and then open up "Pictures"
Please help.
Thanks

Well, I take everything back. After removing all password entries and re-installing/rebooting, it worked for a while. But now it is doing it all over again. I tried to call techincal support, but they then said I would have to pay for software support and they only support hardware, and to re-install the OS. Great, jeez, I couldn't have tried that myself, and that is so simple and takes no time at all (detecing sarcasm yet?)
I do a lot of work for large corporations that are watching the IBM=>Lenovo takeover very closely to see if they are going to drop Thinkpads altogether and go with another laptop vendor. This type of weak support does not bode well. The person I was on the phone with was rude, hard to understand, and even told me there was no place to escalate the call to.
There is no replacement for customer support. It is sad to see no Lenovo involvement in this forum, and don't make the mistake of thinking this is an isolated problem at this time. It is growing.
Though Thinkpads are great Laptops, Toshiba used to have the market, but their support or should I say lack of it led to their downfall and position of leadership loss.
It will be no different if Lenovo continues to act like a machine churner.

How to enable SHA-2 hashing algorithm support on windows 7

Hello All,
Please suggest how to invalidate SHA-1 and MD5 algorithm on windows 7 and how to enable SHA-2.
As suggested by Microsoft, regarding the availability of SHA-2 hashing algorithm, security update KB2949927 is installed on windows 7.
Thank You

Hi,
Please check if you have installed the below mentioned update:
http://support.microsoft.com/kb/2973337/en-us
After installing this update, SHA512 is enabled for TLSv1.2.
IE shall also be using TLS internally. Hope that should resolve your problem.
Please refer to the below link for a similar discussion and its solution posted there:
https://social.technet.microsoft.com/Forums/office/en-US/857c6804-8ce1-4f09-b657-00554055da16/tls-12-and-sha512?forum=winserversecurity
(Please mark as answer if it resolves your issue. Please upvote if it is helpful.)
Regards,
Rajesh

Apple Configurator Wi-Fi password bug? or just need to RTFM?

I've been playing around with the new Apple Configurator for a few days now and have run into a problem when creating profiles that I want to install on a few iPad 2s. I'm either doing something fundamentally wrong and need to RTFM more closely, or there's a bug in the software that I'm hoping someone could (a) confirm and (b) provide a workaround.
The problem is when I define a Wi-Fi payload for a network that uses WPA2 Enterprise (PEAP with user/pass RADIUS authentication) in that Apple Configurator steadfastly refuses to save the password. I've tried installing Configurator on a couple of different Macs and have been able to replicate this problem on each of them. I have also tried recreating the profile in Configurator and also importing a profile into the it from IPCU. In this scenario, Configurator *does* remember the Wi-Fi password, but does *not* remember/honor the passcode timeouts. Furthermore, *any* changes I make to the imported profile wipes the saved Wi-Fi password.
I realize that this is 1.0 software, but somehow I expected something a little bit more polished from Apple (afterall, it's not "0.9b"). So the question for the community is this: Am I doing something wrong or is this simply a bug? Is there a workaround that anyone has discovered?
TIA,
Mike

Thanks for the reply. I was in touch with a Apple engineer who also recommended that I file a bug report. The Bug ID for this is: 11054681.
In the meantime, I was able to figure out a workaround.
Create configuration profiles in IPCU for (a) Wi-Fi (b) Passcode settings and (c) Everything else
Export each of those config profiles
Using Apple Configurator, import those profiles into it using the "+" button
Prepare and Supervise the devices as usual.
So long as I don't touch the Wi-Fi or Passcode profile, Configurator honors the password and passcode settings and applies them to the iOS devices as expected. Another reason to use IPCU for the passcode settings is that IPCU allows for Autolock to be set up to 15 minutes whereas Configurator only allows for up to 5 minutes.
Another bug (feature?) that I noticed is that if you have a configuration profile that contains Web Clips, Configurator duplicates those Web Clips on the iPad when you make and apply changes to a supervised device. If the Web Clip is defined as "Not Removable", you're left with multiple copies of the same Web Clip on the iPad. The only way I was able to get around that was to either (a) not use Web Clips or (b) Erase all Settings from the iPad and allow Configurator to reapply the config everytime I made any changes to the iPad. I also filed a bug report for this behavior (Bug ID# 11054780)
Anyhow, Configurator has a lot of promise, just a lot of bugs for a 1.0 release.
Regards
Mike

HT203192 "networksetup is trying to modify the system network configurations" type your password to allow this.

"networksetup is trying to modify the system network configurations" type your password to allow this.Type your password to allow this. No amount of password typing seems to satisfy the request. The pop up box will not go away!!!!

Hi Glenyse,
Did you find the answer to your question? I have the same problem. Or can anyone else help?
My wife’s 2012 Macbook Pro has Yosemite and is using Wi Fi for the internet connection.
Every time, both on startup and awaking from sleep, a window appears on the desktop with a locked icon saying, “Networksetup is trying to modify this system. Type your password in to allow this”.
The window (which can’t be moved or dragged) shows the computer’s user name. The password has to be repeatedly typed in as many as 10 times and the highlighted ‘modify configuration’ box clicked before the window disappears and the computer then functions normally.
Needless to say, this is driving my wife up the wall… I would certainly appreciate information on how to get rid of this troublesome window!

Password hashes in OSX Mavericks

Where are password hashes stored and how are they stored?

HI nytrash,
Please let me know what is the version of Acrobat you are using. Or it is reader that is installed on your machine.
Regards.

Configuring AD LDS Password Hash Algorithm

Similar Messages

Maybe you are looking for