Suse + Active Directory - User & Group privileges locally

SUSE Linux Enterprise Server SLES Networking
1

So I have added a test machine to Active Directory, can login without issue with either user or Admin account. However, purpose is to administer these Linux servers with AD credentials, not merely log in. In other words the domain administrator needs to have near root level access to the local machine. What I find is that I can not even get a service status unless I switch to root/local user account. So it seems these domain accounts have the least level of privileges.

The test VM is Suse Enterprise Server 11 SP3 along with Windows 2008 R2. I have utterly failed to find any relevant documentation, or even blog post. All I have found so far is process of simply adding Linux to AD domain.

Any links to tutorials or documentation would be super.

2

All users other than root are plain old users. If you want a plain old
user to do something special you can do things like use ‘sudo’ or similar
programs (NetIQ/Novell Privileged User Manager (NPUM)) to make this
more-automatic, policy-based, and very configurable. As a general
security principle, though, running as somebody powerful 24x7 is a bad
idea, which is why things like ‘sudo’ require you to use the ‘sudo’
command to cal something as another user, so then you do not need to worry
about accidentally destroying your computer unless you are also using
‘sudo’ at the same time. The same applies for most things that provide
elevated privileges, though NPUM has an option to use a powerful shell, so
even though you login as your user you immediately become very powerful.

For what you want to have happen, NPUM is for you. For everybody else,
‘sudo’ is usually the best bet. sudo configuration can be centralized in
an LDAP directory, so that may be something for you to work out as well so
that you can give ‘joe’ rights to run Apache httpd-related commands on
boxes, and ‘Janet’ access to run filesystem quota commands on boxes,
without touching every single box for every single change in rights that
ever happens.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

3

Not an issue so much as running something 24x7 as root, but rather ability to manage accounts and access centrally. In other words I dont want have go to say 10 or 20 machines and change each password for given account, but rather do so centrally. Or have ability for example to add apache user account to a given group, have change made across all servers at once.

I can tell you that NetIQ is not solution for us, simple matter of budget. So can I assume if we changed authentication from Samba to anything else, be same?

4

On 08/02/2014 04:54 AM, swaite wrote:[color=blue]

Not an issue so much as running something 24x7 as root, but rather
ability to manage accounts and access centrally. In other words I dont
want have go to say 10 or 20 machines and change each password for given
account, but rather do so centrally. Or have ability for example to add
apache user account to a given group, have change made across all
servers at once.[/color]

Of course, and this is what directory integration is all about, and should
work already.
[color=blue]

I can tell you that NetIQ is not solution for us, simple matter of
budget. So can I assume if we changed authentication from Samba to
anything else, be same?[/color]

It may be worthwhile to talk about some philosophy behind security just in
case it has not come up before, as you already mentioned authentication.
Authentication via a directory is simple, and that is what Samba
integration gives you. Having groups in the directory also Posix-enabled
should mean that the same groups can show up on the *nix systems linked to
their respective users who are on that same *nix system. That’s what a
directory gives you; lots of automated, simple, centralized
authentication. Hooray!

What you are asking about is not authentication, but authorization. That
you can login meas you can authenticate; what you do from there is all
about authorization and is another issue entirely. Are you authorized to
start/stop services? Normally that kind of thing is granted to the user
that started the service (a service account as which nobody would ever
authenticate since it’s a service account, or maybe ‘root’ which implies
complete control given to somebody who can become ‘root’, etc.) or else is
delegated using things like ‘sudo’ and ‘PUM’ or similar technologies.

If you want to authorize something centralized, merely authenticating to
any source of authentication information will not get you there. For the
free option, ‘sudo’ is probably your best bet since you can configure sudo
to get its configuration data from a directory.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…