4
Common Passwords list and several Password requirements not working!
Problem reported by Jay Altemoos - 9/6/2018 at 9:42 AM
Resolved
Good morning everyone. So I have an issue, we are running SmarterMail Enterprise 15.7.6754, this morning we discovered that for some reason the common_password list is not working at all anymore. We have the box checked under the Security -> Password Requirements -> Prevent commonly used passwords. We discovered this morning that one of the domain admins created an email account with a password of password. Checking the common_passwords.xml file there is an entry in there <password>password</password>. I tested it on our domain with a temp account and it allowed me to set the password as password, which it should not be able to allow that. The password box does not change to pink like it used to if a password was not allowed.
 
Here's the settings we have checked in the Security section:
 
Require a number in the password
Require a lower case letter in the password
Require a symbol in the password
Require password does not match username
Prevent commonly used passwords
Disable password strength for existing passwords
 
None of the above Security settings are working at all. It allows me to create a password the same as the username, when it should not allow that at all.
 
Anyone else having this issue? Or has anyone reported this error? I didn't see anything in the revision history notes in the latest release that addresses this. Prior to us updating to this release the security measures were working fine.

7 Replies

Reply to Thread
1
Andrea Free Replied
Employee Post
Hi Jay,
 
I tested this on our latest public release, 15.7.6821, and the previous release for 15.7.6754. I'm not able to replicate the issue in either build. One thing I'd like to check before submitting your ticket to the Support Department... Did the Domain Admin log in directly to the Domain Admin account, or was he logged in as the System Admin impersonating the domain? In 15.x, password requirements are bypassed when a System Administrator impersonates a Domain Admin and creates or edits a user. Is that perhaps the case you're seeing? 
 
In both versions, when I am logged in as the System Admin and impersonate a Domain Admin account (or use the domain's Manage button), I can set user passwords to anything. There are no restrictions. However, when "Disable password strength for existing passwords" is disabled, the user is prompted on the login page to update their password to meet system requirements. If I am logged in with a Domain Admin account, I am not able to set a user's password to something that doesn't meet system requirements. 
Andrea Free SmarterTools Inc. 877-357-6278 www.smartertools.com
2
Jay Altemoos Replied
Hi Andrea, thank you for taking the time to test, when I logged in I was logged in as a System Admin. Let me create a dummy domain admin on our domain and test. I will report back my findings. I had no idea the System Admin would bypass all those settings. I don't recall seeing that mentioned in the help manual. If it's there I must have missed it, if it's not there, it really should be added. I will report back shortly. Thank you.
1
Jay Altemoos Replied
Alright I have tried my test and the situation gets even weirder than before:
 
1. If a create a brand new domain admin account on a domain that never had a domain administrator and try one of the common passwords, a red box appears at the top of the screen notifying me of password complexity requirements are not met. So that is working as it should.
 
2. If I log into a previous account that has a domain admin (not impersonate), in this case I logged into the account that was able to make the simple password initially, it just lets me create a user account with any password I want and ignores the password requirements as I posted above. I verified that this user is in fact a Domain Admin and he is and only sees their own users. So I took this a step further in the next step.
 
3. So on the same domain where the domain admin can create any password they want, I created a brand new domain admin account, log out and log into they fresh domain admin account I can create any password I want just like I did with the previous domain admin.
 
4. I logged into another domain that has had a domain admin and tried the same test, I get the same results as i did for the previous domain. I can create any password i want without the system stopping me.
 
So here's my observations on this, any domain we host that has had domain admins on them through the various updates we have done can create user accounts with any passwords they want without being subjected by the password requirements. Even if I create a new domain admin on those same domains that have had domain admins on them previously also exhibit the same behavior of not being subjected to the password requirements section as if they were a System admin, but without the entire list of every domain we host. Now if I go to a domain we host that has never had a domain admin and create a fresh one for the first time, then the rules apply here like they should if i try to create a password that is either on the common_passwords list or any of the password requirements we have in place.
 
I even went as far as revoking a domain admin, logging in as them as a regular user, logging out, upgrading their domain admin rights again, log back in and I am back to square one with being able to create any password I want and not be subjected to the password requirement section again.
 
So I went a step further and logged into the console of the server, went to their domain folder, went to the domain admin account on that domain and checked the userConfig.xml file to be sure it had them listed as a domainAdmin and it does. So there you have it and I am certain that tech will need to get involved with this.
 
I am guessing that you created a new domain admin on your test copy for a domain that never had one correct? Do you have a domain on your test box that has had a domain admin for awhile and has been through several updates?
 
 
0
Jay Altemoos Replied
Hey Andrea, just checking in on this, has anyone from tech or a dev looked this over? Do I need to open a ticket?
 
Let me know.
 
Thank you.
0
Jay Altemoos Replied
Support ticket submitted on this.
1
Jay Altemoos Replied
Marked As Resolution
Just an update on this if anyone is running into this same scenario, SM devs figured out the issue and provided me with a early build to fix this. So if anyone else is running into this problem, I would reach out to SM tech to get a early build or just wait for the next release. This was happening on 15.7.6821. The build they provided me was 15.7.6844. Not sure if anyone on version 16 might be having this same problem.
0
Andrea Free Replied
Employee Post
Thanks for the update, Jay! 
Andrea Free SmarterTools Inc. 877-357-6278 www.smartertools.com

Reply to Thread