As a Hosting Provider, I want to create root-level sysadmins without fake cPanel accounts, so that users do not see WHM users listed in cPanel Accounts
Confuses a lot of our users when they see the dummy domain we picked for their WHM account in the list. Much better to seperate WHM users so they don't need a cPanel account with elevated privs.
This is a feature that has been migrated over from the cPanel Forums. All previous comments and discussions concerning this feature can be located at:
http://forums.cpanel.net/f145/root-level-sysadmins-without-fake-cpanel-accounts-241451.html
I like this idea 
As a workaround for wanting to create a reseller account without creating a cPanel account, you can use these steps. Note: as these users are given root access, this user will be able to manage accounts not owned by them.
As a workaround for wanting to create a reseller account without creating a cPanel account, you can use these steps. Note: as these users are given root access, this user will be able to manage accounts not owned by them.
As a workaround for wanting to create a reseller account without creating a cPanel account, you can use these steps. Note: as these users are given root access, this user will be able to manage accounts not owned by them.
As a workaround for wanting to create a reseller account without creating a cPanel account, you can use these steps. Note: as these users are given root access, this user will be able to manage accounts not owned by them.
this would be helpful and a lot cleaner.
this would be helpful and a lot cleaner.
Until we provide native functionality to accomplish this, the following document should help you do this: http://docs.cpanel.net/twiki/bin/view/AllDocumentation/WHMDocs/CreateAccountwithoutdomain
Until we provide native functionality to accomplish this, the following document should help you do this: http://docs.cpanel.net/twiki/bin/view/AllDocumentation/WHMDocs/CreateAccountwithoutdomain
We need this!
We are a hosting provider and would be very useful for us the posibility of give more privileges without "Root Access" in reseller privileges. We need users that could work with all accounts and do more things on WHM without the full access with which they have the posibility of "change root password" for example.
Thank you!
We need this!
We are a hosting provider and would be very useful for us the posibility of give more privileges without "Root Access" in reseller privileges. We need users that could work with all accounts and do more things on WHM without the full access with which they have the posibility of "change root password" for example.
Thank you!
Disable WHM login with a password, and enable login to WHM with a Key Pair (i.e. an SSH key). Between that and restricting root logins to explicitly allowed IPs with /etc/security/access.conf is a good way to help try preventing hacking. We see attempts to brute the root password all the time.
I would be leary of trusting a reseller when you do not want to give out root access in the first place.Should be easy enough to set this up through WHM, except there is not yet an option to log into WHM with a keypair. I know that is the only reason we have not completely disabled root passwords.
Disable WHM login with a password, and enable login to WHM with a Key Pair (i.e. an SSH key). Between that and restricting root logins to explicitly allowed IPs with /etc/security/access.conf is a good way to help try preventing hacking. We see attempts to brute the root password all the time.
I would be leary of trusting a reseller when you do not want to give out root access in the first place.Should be easy enough to set this up through WHM, except there is not yet an option to log into WHM with a keypair. I know that is the only reason we have not completely disabled root passwords.
I encourage further discussion and feedback on this and what feature(s) specifically system administrators find themselves having to extend out to 3rd parties which they do not feel comfortable extending them full root access to.
The biggest problem I see with this is that exposing "limited" functionality to some features would imply or otherwise allow a method for the user to escalate themselves to full privileges or in excess of what you were intending.
The most obvious of which would be giving a limited access account the ability to change the root password, manage root ssh keys, change the MySQL root password, or even manage a DNS Cluster (since that would imply access to the root access hash, and therefore root). The concept of trying to "limit" root access to compartments of features is seemingly almost self-defeating in this respect with many features.
It would be very important, as a result, to find out what features administrators are attempting to limit access to and thus review that with a security mindset and see if it's feasible in the first place.
I encourage further discussion and feedback on this and what feature(s) specifically system administrators find themselves having to extend out to 3rd parties which they do not feel comfortable extending them full root access to.
The biggest problem I see with this is that exposing "limited" functionality to some features would imply or otherwise allow a method for the user to escalate themselves to full privileges or in excess of what you were intending.
The most obvious of which would be giving a limited access account the ability to change the root password, manage root ssh keys, change the MySQL root password, or even manage a DNS Cluster (since that would imply access to the root access hash, and therefore root). The concept of trying to "limit" root access to compartments of features is seemingly almost self-defeating in this respect with many features.
It would be very important, as a result, to find out what features administrators are attempting to limit access to and thus review that with a security mindset and see if it's feasible in the first place.
I understand all of this, I agree security is a big issue. What I am specifically looking to provide access to (which I do for all my techs on our VPS nodes with SolusVM) is allow them access to third party plugins like firewall and such.
Basic functions that you don't want just any tech having access to.
I understand all of this, I agree security is a big issue. What I am specifically looking to provide access to (which I do for all my techs on our VPS nodes with SolusVM) is allow them access to third party plugins like firewall and such.
Basic functions that you don't want just any tech having access to.
I would also add...
- restore account backups
- limited account modifications, for example changing main domain name that can't be performed through WHMCS, changing badwidth, disk quota and contact email, but not to be able to terminate accounts
I would like to be able to have different admin user levels, for example one admin should be very limited and have only some basic features, and some admins should have access to tweak config and other service configurations, al most like root access, but again without options to change root pass, ssh keys, dns cluster configuration, and other sensitive root only features.
Of course some granular ACL would be perfect, but for start I would be happy to have basic ability to create admin users that have access similar to a reseller user and current reseller ACL, plus backup restoration feature.
I would also add...
- restore account backups
- limited account modifications, for example changing main domain name that can't be performed through WHMCS, changing badwidth, disk quota and contact email, but not to be able to terminate accounts
I would like to be able to have different admin user levels, for example one admin should be very limited and have only some basic features, and some admins should have access to tweak config and other service configurations, al most like root access, but again without options to change root pass, ssh keys, dns cluster configuration, and other sensitive root only features.
Of course some granular ACL would be perfect, but for start I would be happy to have basic ability to create admin users that have access similar to a reseller user and current reseller ACL, plus backup restoration feature.
I would be interested in hearing if other server administrators share this opinion and would like this behavior.
Essentially, what I imagine you're asking for, is the equivalent of the Linux OS and how you can disable direct 'root' logins and setup a user to sudo from.
In this case, you could utilize a reseller with the 'root' privilege/ACL and disable login to WHM as 'root' directly.
Would this meet your needs?
Combined with disallowing direct root login over SSH and using a wheel user, this would help further limit direct root logins and allow obfuscation through a secondary username. As you say, it would make it more difficult to brute force.
Just like with using a wheel user for SSH, though, security through obscurity is not a replacement for genuine security practices (up-to-date kernel, up-to-date cPanel, secure passwords, etc)
I would be interested in hearing if other server administrators share this opinion and would like this behavior.
Essentially, what I imagine you're asking for, is the equivalent of the Linux OS and how you can disable direct 'root' logins and setup a user to sudo from.
In this case, you could utilize a reseller with the 'root' privilege/ACL and disable login to WHM as 'root' directly.
Would this meet your needs?
Combined with disallowing direct root login over SSH and using a wheel user, this would help further limit direct root logins and allow obfuscation through a secondary username. As you say, it would make it more difficult to brute force.
Just like with using a wheel user for SSH, though, security through obscurity is not a replacement for genuine security practices (up-to-date kernel, up-to-date cPanel, secure passwords, etc)
It seems to me that adding two factor authentication and limiting WHM root logins to specific IPs would be more beneficial to prevent brute forcing of root. Both methods are already in the works if I recall.
It seems to me that adding two factor authentication and limiting WHM root logins to specific IPs would be more beneficial to prevent brute forcing of root. Both methods are already in the works if I recall.
I vote for more granularity on user permissions.
Example: the [root] user have full access, the [reseller] user has limited access .
There is a huge gap between them!
But there are a number of items a [reseller] user could gain access without being [root].
For example: tweak settings , exim and spam assassin , restart services, email queue, check logs ... These items could be allowed to the [reseller], dont?
This is interesting especially when we outsource server management with another company.
This way some [root] privileges would remain unique to the [root] user, but others could be shared with the [reseller] user.
Make sense?
I vote for more granularity on user permissions.
Example: the [root] user have full access, the [reseller] user has limited access .
There is a huge gap between them!
But there are a number of items a [reseller] user could gain access without being [root].
For example: tweak settings , exim and spam assassin , restart services, email queue, check logs ... These items could be allowed to the [reseller], dont?
This is interesting especially when we outsource server management with another company.
This way some [root] privileges would remain unique to the [root] user, but others could be shared with the [reseller] user.
Make sense?
I would like this feature so that we can grant more privileges to customers on their fully managed servers. For example, we would like to allow our customers to create reseller accounts but still prevent any "destructive" actions such as tweaking configurations.
I would like this feature so that we can grant more privileges to customers on their fully managed servers. For example, we would like to allow our customers to create reseller accounts but still prevent any "destructive" actions such as tweaking configurations.
I was wondering if there are any updates to this feature request, because I agree it would be extremely valuable, especially if someone wants to delegate admin privileges without having to give out the root password unless extremely necessary.
I would also like to confirm if the above method is still recommended if the feature is not available, because I see there is a warning about using that method.
I was wondering if there are any updates to this feature request, because I agree it would be extremely valuable, especially if someone wants to delegate admin privileges without having to give out the root password unless extremely necessary.
I would also like to confirm if the above method is still recommended if the feature is not available, because I see there is a warning about using that method.
Given the recent change in licencing I reinforce the need for this feature.
Given the recent change in licencing I reinforce the need for this feature.
I would love to see the delegation of administrative access implemented so that the root password can be kept confidential. Creating additional administrators and providing them with more limited permissions helps to keep the system more secure and allows you to track changes. Especially when you need a helpdesk team to be able to create accounts, perform DNS changes and reset user passwords. Having to provide a root password to helpdesk staff, which are generally known to have quite a bit of turnover, is not the best thing to do. Even if you frequently change the password. Yes, of course we keep backups so we can perform a restore in case the system is compromised, but it's better if it doesn't come to that.
I have seen the method/advice of creating a reseller account without a domain, but at the same time the doc that describes the method states: "We strongly recommend that you do not use this method to create administrative user accounts. This method can cause problems with your server configuration."
Then why is this the recommended workaround, even by cPanel staff ? And how can it cause problems with the server config?
I would love to see the delegation of administrative access implemented so that the root password can be kept confidential. Creating additional administrators and providing them with more limited permissions helps to keep the system more secure and allows you to track changes. Especially when you need a helpdesk team to be able to create accounts, perform DNS changes and reset user passwords. Having to provide a root password to helpdesk staff, which are generally known to have quite a bit of turnover, is not the best thing to do. Even if you frequently change the password. Yes, of course we keep backups so we can perform a restore in case the system is compromised, but it's better if it doesn't come to that.
I have seen the method/advice of creating a reseller account without a domain, but at the same time the doc that describes the method states: "We strongly recommend that you do not use this method to create administrative user accounts. This method can cause problems with your server configuration."
Then why is this the recommended workaround, even by cPanel staff ? And how can it cause problems with the server config?
Definitely need a feature like this.
I need a way to allow first level support to manage accounts without the ability to change Apache/Exim and other settings. And this should be separate from the reseller functionality.
Definitely need a feature like this.
I need a way to allow first level support to manage accounts without the ability to change Apache/Exim and other settings. And this should be separate from the reseller functionality.
It is added to Cpanel 100.
Please check:
https://docs.cpanel.net/knowledge-base/accounts/how-to-create-a-whm-reseller-without-an-associated-domain/#use-the-whm-api-1-createacct-function-to-create-a-whm-reseller-account-without-an-associated-domain
It is added to Cpanel 100.
Please check:
https://docs.cpanel.net/knowledge-base/accounts/how-to-create-a-whm-reseller-without-an-associated-domain/#use-the-whm-api-1-createacct-function-to-create-a-whm-reseller-account-without-an-associated-domain
As Orlando pointed out, we do now have a supported method for this. That being said, I wonder if it meets the expectations described here. It also sounds like a WHM UI equivalent to accomplish this would be additionally useful.
As Orlando pointed out, we do now have a supported method for this. That being said, I wonder if it meets the expectations described here. It also sounds like a WHM UI equivalent to accomplish this would be additionally useful.
Replies have been locked on this page!