Univention Bugzilla – Bug 31648
Do not automatically change (machine) secrets
Last modified: 2013-09-30 08:42:38 CEST
Rationale: There are many passwords in UCS that are not (normally/regularly) typed in manually. For example the /etc/machine.secret, /etc/ldap.secret, and the like. As these passwords are only used in automatic scripts the length does not need to be limited to be practical (to type them manually). For security these passwords should thus be created with as much entropy as the password hash function preserves. (Current default: 512 b) This will remove the possibility of brute force attacks (either online or offline) Currently they contain a very minimal amount of entropy as noted in Bug #31281. As these passwords can not be guessed given enough time, there is no security to be gained from regularly changing them: If it can be obtained via other means a monthly change still leaves long periods of vulnerability and the new password can be obtained the same way after rotation. Also an automatic password rotation can (and has in the past) lead to problems possibly crippling whole UCS domains. Actions: For every such password: *) As noted in Bug #31281 there should be a library function to securely create a password of this optimal length (an UCRV for length configuration is not necessary, the length can be derived from the current password hashing method which is already in UCR) *) The automatic password rotation for these passwords should be removed to reduce complexity and remove a possible failure mode. However the code shall be kept/modified so that there is still a documented way to rotate a specific password if required (for example if a server is stolen).
> these passwords can not be guessed given enough time *can*
I guess we should leave this decision up to the customer policies. Samba4 e.g. requires password change for DCs according to the chosen domain policy.
Ok, http://blogs.technet.com/b/askds/archive/2009/02/15/test2.aspx sais: "Machine account passwords as such do not expire in Active Directory. They are exempted from the domain's password policy. It is important to remember that machine account password changes are driven by the CLIENT (computer), and not the AD. As long as no one has disabled or deleted the computer account, nor tried to add a computer with the same name to the domain, (or some other destructive action), the computer will continue to work no matter how long it has been since its machine account password was initiated and changed." A test showed that Samba 4.0.3 conforms to this, at least for the Samba4 DCs.
We discussed this issue in various discussions. but a lot of customers will require this "feature". Or at least the security audit of the customer even if it makes no sense to rotate the password.