Okay, we think we have it figured out. When we go with a fixed initialization 
vector the servers can read each other's credentials cache. From our developer:

IV is stored locally? in a ConcurrentHashMap, presumably in memory, but this 
hash map is not being propagated to other servers in a clustered environment? 
So when cas1 goes to look up the IV for a user (hashedKey) that was stored in 
cas0's memory, we believe that's where we're getting a null hashedKey and have 
verified that decrypting using a different IV (even null) results in 
BadPaddingException. Effectively, there's no way for cas1 to know what was 
stored in cas0's ConcurrentHashMap unless it was on the same system. Hence 
ClearPass works reliably when it's only on one system but not when it's 
clustered. We are currently testing with a static IV and if this works, are 
suggesting at this time that IV values are somehow accessible from any node 
(e.g. saved to decoratedMap/memcachedMap?)

He is working on a fix for our installation. 

----------------------------------
Mark St. Laurent
Web Systems Administrator
Yavapai College
(928) 717-7654
http://www.yc.edu 


-----Original Message-----
From: St Laurent, Mark 
Sent: Tuesday, November 19, 2013 10:20 AM
To: [email protected]
Subject: RE: [cas-user] ClearPass with Load-Balanced CAS

>From my Java developer:

For the mailing list, see if the following information is what they're looking 
for (it appears that on both systems, the CIPHER_ALGORITHM and 
SECRET_KEY_FACTORY_ALGORITHM are supported as below):

Cipher.ARCFOUR SupportedModes ECB
Cipher.AES SupportedModes 
ECB|CBC|PCBC|CTR|CTS|CFB|OFB|CFB8|CFB16|CFB24|CFB32|CFB40|CFB48|CFB56|CFB64|OFB8|OFB16|OFB24|OFB32|OFB40|OFB48|OFB56|OFB64|CFB72|CFB80|CFB88|CFB96|CFB104|CFB1
Cipher.AESWrap SupportedModes ECB
Cipher.Blowfish SupportedModes 
ECB|CBC|PCBC|CTR|CTS|CFB|OFB|CFB8|CFB16|CFB24|CFB32|CFB40|CFB48|CFB56|CFB64|OFB8|OFB16|OFB24|OFB32|OFB40|OFB48|OFB56|OFB64
Cipher.RC2 SupportedModes 
ECB|CBC|PCBC|CTR|CTS|CFB|OFB|CFB8|CFB16|CFB24|CFB32|CFB40|CFB48|CFB56|CFB64|OFB8|OFB16|OFB24|OFB32|OFB40|OFB48|OFB56|OFB64
Cipher.DES SupportedModes 
ECB|CBC|PCBC|CTR|CTS|CFB|OFB|CFB8|CFB16|CFB24|CFB32|CFB40|CFB48|CFB56|CFB64|OFB8|OFB16|OFB24|OFB32|OFB40|OFB48|OFB56|OFB64
Cipher.DESedeWrap SupportedModes CBC
Cipher.RSA SupportedModes ECB
Cipher.DESede SupportedModes 
ECB|CBC|PCBC|CTR|CTS|CFB|OFB|CFB8|CFB16|CFB24|CFB32|CFB40|CFB48|CFB56|CFB64|OFB8|OFB16|OFB24|OFB32|OFB40|OFB48|OFB56|OFB64
Cipher.RSA SupportedModes ECB

Cipher.DES SupportedPaddings NOPADDING|PKCS5PADDING|ISO10126PADDING
Cipher.RSA SupportedPaddings 
NOPADDING|PKCS1PADDING|OAEPWITHMD5ANDMGF1PADDING|OAEPWITHSHA1ANDMGF1PADDING|OAEPWITHSHA-1ANDMGF1PADDING|OAEPWITHSHA-256ANDMGF1PADDING|OAEPWITHSHA-384ANDMGF
Cipher.AES SupportedPaddings NOPADDING|PKCS5PADDING|ISO10126PADDING
Cipher.Blowfish SupportedPaddings NOPADDING|PKCS5PADDING|ISO10126PADDING
Cipher.ARCFOUR SupportedPaddings NOPADDING Cipher.AESWrap SupportedPaddings 
NOPADDING Cipher.DESede SupportedPaddings NOPADDING|PKCS5PADDING|ISO10126PADDING
Cipher.DESedeWrap SupportedPaddings NOPADDING
Cipher.RC2 SupportedPaddings NOPADDING|PKCS5PADDING|ISO10126PADDING
Cipher.RSA SupportedPaddings PKCS1PADDING

SecretKeyFactory.DESede com.sun.crypto.provider.DESedeKeyFactory
SecretKeyFactory.PBEWithMD5AndDES 
com.sun.crypto.provider.PBEKeyFactory$PBEWithMD5AndDES
SecretKeyFactory.DES com.sun.crypto.provider.DESKeyFactory
SecretKeyFactory.PBEWithMD5AndTripleDES 
com.sun.crypto.provider.PBEKeyFactory$PBEWithMD5AndTripleDES
SecretKeyFactory.PBKDF2WithHmacSHA1 
com.sun.crypto.provider.PBKDF2HmacSHA1Factory
SecretKeyFactory.PBEWithSHA1AndDESede 
com.sun.crypto.provider.PBEKeyFactory$PBEWithSHA1AndDESede
SecretKeyFactory.PBEWithSHA1AndRC2_40 
com.sun.crypto.provider.PBEKeyFactory$PBEWithSHA1AndRC2_40

Thanks, 

----------------------------------
Mark St. Laurent
Web Systems Administrator
Yavapai College
(928) 717-7654
http://www.yc.edu 


-----Original Message-----
From: Misagh Moayyed [mailto:[email protected]]
Sent: Monday, November 18, 2013 4:56 PM
To: [email protected]
Subject: RE: [cas-user] ClearPass with Load-Balanced CAS

Next suspect is encryption cipher and/or key algorithm. The defaults are 
"AES/CBC/PKCS5Padding" and "PBKDF2WithHmacSHA1". 

Can you try something like this to see what is offered by Java?
http://stackoverflow.com/questions/9333504/how-can-i-list-the-available-ci
pher-algorithms

> -----Original Message-----
> From: St Laurent, Mark [mailto:[email protected]]
> Sent: Monday, November 18, 2013 12:16 PM
> To: [email protected]
> Subject: RE: [cas-user] ClearPass with Load-Balanced CAS
> 
> Tried this, produces the same error.
> 
> ----------------------------------
> Mark St. Laurent
> Web Systems Administrator
> Yavapai College
> (928) 717-7654
> http://www.yc.edu
> 
> 
> -----Original Message-----
> From: Misagh Moayyed [mailto:[email protected]]
> Sent: Friday, November 15, 2013 6:30 PM
> To: [email protected]
> Subject: RE: [cas-user] ClearPass with Load-Balanced CAS
> 
> Lets remove other variables: what happens when you test without the 
> salt
and
> the secret key from all nodes, relying on the defaults?
> 
> > -----Original Message-----
> > From: St Laurent, Mark [mailto:[email protected]]
> > Sent: Friday, November 15, 2013 1:23 PM
> > To: [email protected]
> > Subject: RE: [cas-user] ClearPass with Load-Balanced CAS
> >
> > Yes, there are only two hosts in the cluster and their clearpass- 
> > configuration.xml files are identical.
> >
> > ----------------------------------
> > Mark St. Laurent
> > Web Systems Administrator
> > Yavapai College
> > (928) 717-7654
> > http://www.yc.edu
> >
> > -----Original Message-----
> > From: Marvin Addison [mailto:[email protected]]
> > Sent: Friday, November 15, 2013 12:00 PM
> > To: [email protected]
> > Subject: Re: [cas-user] ClearPass with Load-Balanced CAS
> >
> > > I added the exception stack to the gist.
> >
> > Root cause:  javax.crypto.BadPaddingException: Given final block not
> properly
> > padded
> >
> > I believe you can get that failure mode when attempting to decrypt
> ciphertext
> > with the wrong key. I'm certain it could happen in the case of data 
> > truncation, but that's seems less likely that a deployment problem.
> Since
> > this is a clustered situation, I would think "wrong key" is a more
> likely
> > cause.  Did you take care to sync the one and only key to all hosts 
> > in
> the
> > cluster?
> >
> > M
> >
> > --
> > You are currently subscribed to [email protected] as:
> > [email protected] To unsubscribe, change settings or access
> archives, see
> > http://www.ja-sig.org/wiki/display/JSG/cas-user
> >
> > --
> > You are currently subscribed to [email protected] as:
> > [email protected] To unsubscribe, change settings or access 
> > archives,
> see
> > http://www.ja-sig.org/wiki/display/JSG/cas-user
> 
> 
> --
> You are currently subscribed to [email protected] as:
> [email protected] To unsubscribe, change settings or access
archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-user
> 
> --
> You are currently subscribed to [email protected] as:
> [email protected] To unsubscribe, change settings or access 
> archives,
see
> http://www.ja-sig.org/wiki/display/JSG/cas-user


--
You are currently subscribed to [email protected] as: 
[email protected] To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

--
You are currently subscribed to [email protected] as: 
[email protected] To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user


-- 
You are currently subscribed to [email protected] as: 
[email protected]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Reply via email to