The simplest method I see being used is to compute the number of bits needed to express any single character in a password (or salt) string, and to generate one that's long enough to give you the number of bits that you want:

cat << EOF | bc -l
? want=128
? size=256
? want/(l(size)/l(2))
? size=94
? want/(l(size)/l(2))
? EOF
15.99999999999999999986
19.52830343694838896540

I have no specific guidance to offer beyond noting that since fixing ticket #1846, we're effectively adding less-random salts than we were previously.

I am aware that reducing the char set we are reducing the number of permutations. But truth be told the salt is only used to avoid issues when renaming user accounts (as the default salt uses the principal name so not very random).

What I wonder is if there is any value in 'raising the strength' of the salt, for whatever reason.

If there is we can easily bring it to 20 chars.

Moving to next month iteration.

Moving to next month iteration.

Merge KDC LDAP components to one.

I think the salt size, given its use is ok as currently implemented.
Closing.