Groups vs. Computer Management

I just have a question for anyone whose interested:
When it comes to client-end administrative rights, are you guys more apt to create special-case groups on the server, then transfer them to the client machine (so that some users can have administrative rights) or do you prefer to use the "My Computer -> Manage -->Connect to a computer" option to connect to a client directly via the server and change user rights (add them temporarily to the administrator group on the local machine), perform whatever tasks you/they need to do, then remove them from the administrative group on the local machine.
Curious what you guys think.

I guess the first question is why do they need temp admin rights? If its for software installs you should be handling that at a Help Desk/ IT level, not the end user. That you can evaluate the software before allowing it. Same with any other installation that would require admin rights on a box.

In our architecture there are groups to be able to do anything. We have a group if a user wants to be able to burn cds, one if they need to use floppies, etc. Everything is locked down to a group. Albeit there are very few exceptions where a user is added as a local admin but anything else we will login or Run As in order to accomplish what they need.

So does that answer the question?

Hi ShagDevil the stock answer is that users don't get admin rights. They should only be able to do exactly what they need to do to perform their duties to the organisation.

Firstly, there is no way I would put 50 senior managers' personal assistants in a "special case group"

That would be more for "power users" such as R&D guys, designers and so on. But only in the kind of case where they used specialist software that they were more qualified to administer.

I would haul others into my project room, log them in as an admin on one of my boxes, and make them do whatever under the supervision of myself or one of my staff.

I am of the same mind as Spyrus ..................why would the question arise?

Now, I take a hard line with everyone on this in development situations. If I need you to have admin rights it should be on a development system, NOT a production one. OK so you need two machines............if you can't understand that, maybe you should not be doing what you are doing?............ I have never had any problems with getting the right equipment to carry out development projects.

I suggest that you need to ask whether this is a production environment or a development one, in the first instance?

Just a few thoughts :)

before you decide what is better, the first place to stop is at your organizational security policy. Then take a look at requirements. After that, then evaluate choices.

--TH13

Quote:

---

there are very few exceptions where a user is added as a local admin but anything else we will login or Run As in order to accomplish what they need

---

Well, here's the thing. We basically give our users very limited rights. This really poses no problems for the most part. For software installations/network issues we can login or use runas but, here's my theory.
We can create groups on the server, allowing us to perform administrative tasks on each client computer yadda yadda. But, We like to keep our clients machines clean of accounts and we try not to populate AD with all kinds of groups. Basically, we have 2 accounts on each client machine: the local administrator and a roaming account (for whoever is using the machine). We can easily log-in using the roaming Admin account or we can use runas but, it can be a pain in the ass if you only need to do something trivial. Especially with our systems because logon/logoff are fairly slow due to the complexity of the software we are using on each client.
For example, let's say I need to go in and adjust a few network settings, and maybe change a few running processes, and maybe delete a file or two. Logging off and back on is a royal pain in the ass, using runas is ok but, can be a yet another royal pain in the ass depending on what I need to do.
What I noticed, is that going on to the server and using the Manage option works quick, and easily. I connect to their PC, give them Admin rights locally, do what I need to do, then remove them from the Admin group (locally). No extra groups, no change to their account, no logging off, no changes to the AD. It just seems so damn easy.
But, yes lol, you did answer my question. This is purely a opinion based thread to see how other Admins handle their daily work. Basically, I look for ideas and what better way than asking how other people go about their business.

AhHa! ShagDevil , now I understand you!

Well, isn't that just what a lot of malware is looking for?

I was thinking more of users actually needing the admin rights themselves , rather than you using it as an administrative shortcut.

I would strongly recommend that you suburdinate your administrative convenience to sound security policy.

I would question this "software" that is causing all the problems................... I have never encountered such a problem :(

I think Horse came up with the best point - take all of your requirements in to consideration.

People are very quick to jump on the users should not be admins band wagon as this is the general consensus, normally these people have not administered a domain and probably never will otherwise they would know that in reality not every network is the same and not all requirements are the same. On some networks it may make perfect sense to give a certain user admin rights and on others it may not.

But back to your question - I had a similar problem in my last job and the method you are using is the one I decided to adopt! Like you said it's so damn easy and quick - I used to do it a different way until someone booted from a live cd on a laptop and cachedumped the admin password.... which is what made me start doing it the way you do!

Understanding what you are basing your question on... I still stand by my original post but we use an application called Switch User (su.exe). How it works:

I remote into a PC using a seperate application (Remotely Anywhere, any will work)
I launch su.exe
input my information.
***The original user is still logged in***
a new desktop comes up (much like a remote desktop would)
I am then able to make any changes I need as an admin.
When finished I go to start logoff and it returns to the users desktop

Works great, as easy as your method, maybe maybe not but I don't need to login to 2 systems to get the job done ;)

Appreciate all the responses. This is pretty much what I was looking for. Everyone has a different train of thought (as they should) and hearing the different perspectives helps me figure out the best possible way to approach network management. There were things mentioned I never thought about and well, that's the beauty of threads like this. It's like having a bunch of network admins on tap (and I don't have to fork out any money). :D
as quoted from Guinness "brilliant!"

Quote:

---

Originally posted here by Spyrus
Understanding what you are basing your question on... I still stand by my original post but we use an application called Switch User (su.exe). How it works:

I remote into a PC using a seperate application (Remotely Anywhere, any will work)
I launch su.exe
input my information.
***The original user is still logged in***
a new desktop comes up (much like a remote desktop would)
I am then able to make any changes I need as an admin.
When finished I go to start logoff and it returns to the users desktop

Works great, as easy as your method, maybe maybe not but I don't need to login to 2 systems to get the job done ;)

---

Before I ask my questions, I want you to know that I'm asking for informational purposes, not to put you on the hot seat.

Now, when you say that you have a third party remote control app listening on each workstation, do all of them have the same credentials for sign in? I nearly choked a few admins for this.

Next, you mentioned that you run the su.exe program when you login remotely. By your description, it sounds like the local user has rights to execute that app. Is this the case?

More or less, I rained fire down from the sky on poor desktop management practices. The biggest issue I came across is end users having rights to install any app they like. When you look back to our policy, they have no need to do this because we only support the core business apps. If you look at our helpdesk calls, 60% are for apps that are outside the supported suite. Now, let's not even get into the various security issues of people installing vulnerable versions of real player, winamp, etc., especially when they end up on disk images.

So again, I always use policy and requirements as my weapon of choice. Then I move on to the technical specifics.

thehorse13,

Quote:

---

Now, let's not even get into the various security issues of people installing vulnerable versions of real player, winamp, etc., especially when they end up on disk images

---

That's why we have each user on our network set to limited accounts. They can't install squat (and we like it that way). Sure, we get grumbles but, at least the network stays clean.

I've been using my method as of late (for quick Admin tasks) and it's working fairly well. I don't need much in the way of remote administration because the farthest user computer is about a 200 foot walk. I have taken what you said under consideration though and plan on reviewing security policies comes Tuesday morning. (yeah, I'm taking Monday off damnit, I need it)

What security policies do you feel should take priority? Domain policy? DC policy? Local policy on each user computer? I'm not really looking for a tutorial here, just a recommendation for which policy would have the farthest reaching effects. I'm guessing by default, the Domain/DC policies would obviously be the most potent but, I'm not a huge fan of messing with system wide security policy for trivial admin tasks. Again, thanks for the replies.

LOL. Answering this question is much like when my buddy used to lift the hood of his 1971 GTO and ask me what he should fix first. Heh.

Anyway, the first thing you need to look at is your corporate security policy. This should be where your company's high level objectives, goals and beliefs should be noted. Hanging off this policy should be your procedures, baselines and guidelines. Within that you'll find (more than likely) the policy you need to look for. There should be a place where verbage exists on how AD is to be managed. If you don't find what you're looking for down here, go up the tree towards the more general policy statements. This is also a good way to spot problems or conflicts in your policies even though you're not out to do that specifically.

In the end, my advice to you is to read and understand *all* of the policies at your company then go off and make your final call. There is nothing worse than implementing something that works well only to find out that a technicality in a policy renders it void. It's also a good way to find yourself sidelined when a promotion comes along.

Enough info? If not, hit me up on IRC or such.

--TH13

ShagDevil ,

My advice is to start from the bottom and work up. Ask what the person needs to do their job?

Also, at a higher level, which groups/networks whatever actually need to be connected by anything other than internal mail and the telephone?



:)

1971 GTO.....drooool. The only thing I like better from '71 is a Chevelle.
Anyways,
I think I have a good game plan formulated now. I'll see over the coming weeks how everything turns out. You know, with all this technology these days...it's amazing how I still do most of my planning with pencil & paper. I pretty much learned that from my programming days....yeah, you guessed it, flow charts.
Thanks again for everyone's input on the matter.

Quote:

---

Originally posted here by thehorse13
Before I ask my questions, I want you to know that I'm asking for informational purposes, not to put you on the hot seat.

Now, when you say that you have a third party remote control app listening on each workstation, do all of them have the same credentials for sign in? I nearly choked a few admins for this.

Next, you mentioned that you run the su.exe program when you login remotely. By your description, it sounds like the local user has rights to execute that app. Is this the case?

More or less, I rained fire down from the sky on poor desktop management practices. The biggest issue I came across is end users having rights to install any app they like. When you look back to our policy, they have no need to do this because we only support the core business apps. If you look at our helpdesk calls, 60% are for apps that are outside the supported suite. Now, let's not even get into the various security issues of people installing vulnerable versions of real player, winamp, etc., especially when they end up on disk images.

So again, I always use policy and requirements as my weapon of choice. Then I move on to the technical specifics.

---

The 3rd party remote control app that we use, utilizes AD credentials to remote in. We have a group for remote access and if you are in that group for that OU you can access the PC's in that OU.

Once you remote into the PC, the user does have access to open the SU application. This application again authenticates against the DC's to see if you are an administrator or not. If you are then you login with your Domain rights and can install apps etc. This includes basic applications like 5250 emulators or word.

In short the user can launch the application but without domain admin capability can't do anything. They also don't have access to log into the remote application.

Am I missing some issues here I should look into? I mean I know our security is FAR from exceptional... usability is way higher on our corporate security guidelines than security seems to be. I cringe at some of the issues but after making my recommendations there is only so much I can do.

Quote:

---

Originally posted here by Spyrus
The 3rd party remote control app that we use, utilizes AD credentials to remote in. We have a group for remote access and if you are in that group for that OU you can access the PC's in that OU.

Once you remote into the PC, the user does have access to open the SU application. This application again authenticates against the DC's to see if you are an administrator or not. If you are then you login with your Domain rights and can install apps etc. This includes basic applications like 5250 emulators or word.

In short the user can launch the application but without domain admin capability can't do anything. They also don't have access to log into the remote application.

Am I missing some issues here I should look into? I mean I know our security is FAR from exceptional... usability is way higher on our corporate security guidelines than security seems to be. I cringe at some of the issues but after making my recommendations there is only so much I can do.

---

I was curious simply because I bitched at our admins for doing this process using cleartext protocols. I handed them their domain admin credentials after running a very simple network tool. When they fixed that, I did it again using a keylogger installed using an end user's AD account. After that, they took away most of the horribleness I complained about. LOL. That's all you're missing. ;)

--Th13

Quote:

---

Originally posted here by thehorse13
I was curious simply because I bitched at our admins for doing this process using cleartext protocols. I handed them their domain admin credentials after running a very simple network tool. When they fixed that, I did it again using a keylogger installed using an end user's AD account. After that, they took away most of the horribleness I complained about. LOL. That's all you're missing. ;)

--Th13

---

LOL-- Is that all?!?! I really wish I had a larger impact on the security in our corporation as a whole. I by no means consider myself an expert... In fact if you look at the grand scheme of security I look at myself as a novice. I just take the time to look into different aspects. I understand the gaping holes we have with various applications and with even the core structures like our AD security. Our remote application (remotely anywhere) allows for encrypted connection... on that same note 3/4 of the machines aren't setup to use encrypted. We also have another server that uses 5250 connection (ill let you figure out what it is) and I don't believe that is encrypted either. It should be using ssh instead but noone wants to set that up.

Will a keylogger pickup a remote sessions keystrokes? I can't say i have ever tested it or thought about it.

Keyloggers typically pick up local keystrokes, not remote sessions.

Terminal 5250 is just another horrible mainframe emulation such as erma 3270. I have tons of that crap spread around my environment. Do you use ACF2? It's a horrible mainframe security suite. If you want to kill yourself, go play with it.

We had the same issue but then our C level folks allowed us to rewrite our policies which now include consiquences for bad actions. We've also switched over to a risk based model simply because using the strict list model, we cannot cover every situation that we come into contact with.
OK, I'm starting to run off with the thread. Sorry, now back to our regularly scheduled program.