Dovecot Authentication

[sparek-3]

So....

How is one able to log into an email account when said account's shadow file (/home/%user%/etc/%domain%/shadow) is renamed and no longer present?

I've done the:

/usr/bin/doveadm auth cache flush

And the account still shows up when I do a lookup:

/usr/bin/doveadm auth lookup %email%@%account%

Pulling hairs out at the moment

 

[rpvw]

Do you have a recent backup you can recover the shadow file from ?

 

[sparek-3]

Sorry, in my haste I may have left out some details.

I've still got the shadow file. My point is, even if I rename the shadow file:

mv /home/%user%/etc/%domain%/shadow /home/%user%/etc/%domain%/shadow.old

and

/usr/bin/doveadm auth cache flush

The user email user is still able to log in.

The login information appears to be being cached some where or maybe I've overlooked something.

I had some other errands I had to do and it was just frustrating me that I couldn't explain how that is working. Maybe I missed something, I'll look at it a bit more in-depth now. But I still don't see how it's possible.

Is there another cache that needs to be flushed?

 

[rpvw]

Do you have /home/%user%/etc/%domain%/@pwcache ?

That folder looks like it has files containing an encrypted string that could be a cached password for each user and email account

 

[sparek-3]

This actually stems from a larger issue, which probably needs to be it's own thread an issue.

But you can suspend a resold account.

The reseller can log into the suspended account's cPanel using their reseller password overwrite (if you have that enabled on your server, which we do, perhaps maybe we shouldn't? ... that's a bit beyond the scope here)

Change the password to one of the web hosting account's email accounts.

And then the email account in question is accessible again with the new password.

That would appear to be an oversight some where. Perhaps the reseller shouldn't be able to log into resold accounts with the reseller password overwrite? Or perhaps email account passwords shouldn't be changeable when a web hosting account is suspended?

That's what originally set up this issue. I thought, "how is this guy logging into an email account under a web hosting account that I suspended?"

Then I tried renaming his shadow file and he's still able to log in. I still don't have an answer to that riddle.

 

[sparek-3]

Do you have /home/%user%/etc/%domain%/@pwcache ?

That folder looks like it has files containing an encrypted string that could be a cached password for each user and email account

Ah! That looks to be it. Thanks!

Still not entirely sure how this works, but when I rename the @pwcache folder and do am auth cache flush, with the shadow file missing, that seems to resolve this.

But when you suspend an account, the shadow file just gets *LOCKED* and the @pwcache directory appears to stay present, and logins do not work. So I'm assuming that authentication will first try to validate a password against the shadow file, and if the shadow file isn't present, it attempts to use the @pwcache entry.

This is typically fine, because if there is no reseller then the account can't log into their own cPanel account when it's suspended to change any of the passwords anyway.

I suppose the bigger issue now becomes why the password for an email account on a suspended account is being allowed to be changed.

 

[cPanelLauren]

I suppose the bigger issue now becomes why the password for an email account on a suspended account is being allowed to be changed.

The email user isn't able to log in to the account to even change the password, do you mean the reseller can change the email user's password? I can see just cause for wanting to be able to make these modifications as a reseller or root user.

 

[sparek-3]

I've actually posted more in-depth on that particular issue at:

In Progress - Suspended account, email accounts, root/reseller overwrite

Regarding this particular issue - @rpvw was able to lead me to the resolution here - the existence of the /home/%user%/etc/%domain%/@pwcache cache file.

The issue I am encountering that I (root) am seeing a reseller's resold account email account being used to to authenticate in SMTP to send out spam. Suspending the resold account entirely (for whatever reason, to get their attention, because they didn't listen, etc), the resold account himself can't log into their cPanel. But the reseller can with their reseller overwrite. They can then change the password to the spamming email account and the user can check and/or send out more spam while the account is suspended on the server.

My thoughts are that if an account is suspended, nobody should be able to log into it. What would be the purpose of allowing that? If not to circumvent the actual suspension.

(perhaps this response needs to be moved to the other thread? I was trying to keep the issues separated)

 

[rpvw]

Looking at the What Happens When You Suspend an Account - cPanel Knowledge Base - cPanel Documentation page, it suggests that all the locks are made in the /etc/shadow password file, and that a user should not be able to change any password, and a reseller should also be excluded if the Prevent resellers from unsuspending checkbox was selected when the account was suspended.

Did the reseller access the account before, or after, you deleted the shadow file ?

I do agree that if a root administrator suspends an account, or even just an email account, there should be an option to make that action inviolable. I have struggled with suspending clients email accounts because one of their devices that was connecting to it was compromised and sending spam, but the user just logged into cPanel and re-activated it.

I know I could use a sledge hammer to crack a peanut and suspend the whole hosting account ..... but surely (don't call me Shirley) there should be some less dramatic method of dealing with the issue.

(Please don't bother asking me to open a feature request .... the other day I submitted one about email filters that I thought sensible, and that should need little programming, and would be good for new features PR, but it seems to have disappeared, or got moderated, into /dev/null)

 

[cPanelLauren]

Regarding this particular issue - @rpvw was able to lead me to the resolution here - the existence of the /home/%user%/etc/%domain%/@pwcache cache file.

I did see that and thanks @rpvw (not Shirley though) - I have my own opinions on the necessity for this but I would like to see what becomes of it in the other thread.

(perhaps this response needs to be moved to the other thread? I was trying to keep the issues separated)

You're fine I do see that Michael has that thread and I believe is investigating to prepare a reply to you for that - I'd like to watch there to see where that one goes.

 

[sparek-3]

and a reseller should also be excluded if the Prevent resellers from unsuspending checkbox was selected when the account was suspended.

This was indeed the case.

Locking the suspension just creates an additional /var/cpanel/suspended/user.lock file for the suspended account. And that was present. The reseller was still able to log into the reseller account - with what best I could tell was their reseller overwrite.

Additionally, what appears to happen. When an account (entire cPanel account) is suspended the shadow files for the email accounts on all the domains for that account are changed:

localpart:*LOCKED*hash:number::::::*LOCKED*

The addition of *LOCKED* in the password hash section effectively disables the user from being able to check or authenticate that email account.

When the root/reseller overwrite is used and the individual changes the password, the shadow file gets changed to:

localpart:newhash:number::::::*LOCKED*

So the password hash section gets rewritten with a new hash. The term *LOCKED* still exists at the end of the line, indicating that it was locked at one time.

This to me just spells that this is an unintended consequence of allowing root/reseller overwrite to be used to log into suspended accounts.

I don't really know what the solution is

I'm kind of of the thinking that if an account is suspended - regardless if the reseller/root unsuspension lock file is present or not - nobody should be able to log into the cPanel of the account. I'm not sure what the point of being able to log into a suspended account would be. But I am also open to hearing what everyone else thinks.

I thought about creating a hook to immute the shadow file. But then I would have to create another hook to remove the immute flag before unsuspension and account deletions. And that seems like a hassle.

Keep in mind, I suspect that this also carries over to database user passwords. Those users are also locked in the database server on suspension, but I'm guessing a root/reseller overwrite login will be able to change these as well - although to what end, that's not immediately clear to me - it's not like the email thing.

The reseller could also log in, and remove offending files after suspension resulting in "What malicious files?"

There's really just cause for concern that anybody is even being allowed to log into a suspended account. But like I said, I'm willing to hear what others have to say.