Blocking Lion

Even on a stipend model there's acceptable use that they need to adhere to. Your AUP should speak to supportability if you're in a stipend model, IMHO. Sure, give them the playground, but there's still a fence they need to stay within, that fence being supportability.

j
---
Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

If it were up to me admin rights and developers buying machines with a billion gigs of RAM would be stopped but alas, I am just a drone in a massive hive.

--
Matt Lee, CCA/ACMT/ACPT/ACDT
Senior IT Analyst / Desktop Architecture Team / Apple S.M.E / JAMF Casper Administrator
Fox Networks Group

Machines should be "right sized" for the job and in some cases for the
On 7/20/11 10:53 AM, "Matthew Lee" <Matt.Lee at fox.com> wrote:
user.

Our developers have been transitioning from Windows to Macs in our
organization because our Corporate IT group chose to standardize on a
couple of desktop and laptop computers for all users regardless of the
work they do. I was involved in researching the needs for our developers
and getting them Macs that would fit their needs. They have noticed that
time just compiling code has decreased 10-fold.

A long time ago we bought our Macs with 2 GB RAM standard when Corp IT was
installing 512 MB in their Windows systems. Today, our standard is 4 GB
while they have finally moved to 2 GB. One thing our Mac users rarely
complain about a slow machine. If they do then it's not the hardware
that's bottlenecking. Our Macs also have a longer lifespan in our
environment too. The difference in price has been well worth the
investment.

--

William Smith
Technical Analyst
Merrill Communications LLC
(651) 632-1492

Regardless of the comments people made about having users with admin, this should never be the case or be required. When I took over our mac departments, several so called 'key' members of staff had admin rights. With the backing of my boss, I was able to remove this and prove that I could provide a better service, particularly with Casper, when it came to re-building their machines, pushing out software or plug-ins, etc.

I had to of course put up with an amount of flak from these members of staff, but it was all completely worth it and they are happy without these rights once it was proven to them that they could do everything they needed to be able to do.

Admin is what is says it is, for administering the machine, nothing more.

I would suggest the following:

1) Work out what is required from the various users and how to provide this to them. If you have this solved, then the end user will still be happy. For example, add your developers to the developers group, edit the sudoers file to provide commands that are required. None of our developers have admin rights and in fact a newer developer who joined us bitched about not having admin rights when he arrived and soon found that we were able to provide him everything he required without this and he is happy.

2) Deny access to the store over the network. I've posted this before, but here it is again:

http://support.apple.com/kb/HT3303?viewlocale=en_US

No overhead of analysing processes, no messing around with messages, the store just wont work and (unless you are giving out the admin password for your firewall as well) they can't change it.

I can't stress enough how much you will be helping yourself if you get admin rights removed and you will look back saying why didn't I push for this earlier! If you approach the task clearly and can demonstrate to the end user that they can do everything that they need to be able to do, they will be happy, almost certainly happier than you completely blocking the 'Store'.

Sean

Again, tell that to departments that have had admin rights for years, people who are highly influential in the media market, and you have to have the backing of your boss.

Some of us don't have the fire power we need to strip admin rights. Trust me if I could I would have.

--
Matt Lee, CCA/ACMT/ACPT/ACDT
Senior IT Analyst / Desktop Architecture Team / Apple S.M.E / JAMF Casper Administrator
Fox Networks Group

Easier to ask for forgiveness than permission :)

Trust me, I understand. I'm in the same boat.
---
Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

We've started removing rights lately. Some users have no issues its always the "developers" and artist who need admin rights and 16 gigs of RAM ;)

We don't even manage developers, they can do what they want but they also get no support. I assume if you can code applications you can properly use a computer. If not, you probably shouldn't be a software developer....

just saying..

Are you referring to the local "_developer" group? How does this compare
On 7/21/11 6:55 AM, "Sean Holden" <Sean.Holden at framestore.com> wrote:
to standard users? I've always taken the underscore as signifying that an
item is a system resource and not something to be touched. Not unwilling
to be told I'm wrong.

Also curious about how you determine what goes into your sudoers file. Are
you making your developers present you a list of what they need or are you
giving them access to access specific locations?

--

William Smith
Technical Analyst
Merrill Communications LLC
(651) 632-1492

I see what you did there :) and I agree!!!

Adding developers to group 204(_developer) should be enough for them. What other possible reason would they supply you with?

As for artists, admin rights just to draw pretty pictures?!?! Just tell them to follow the number/colour chart :) If they give you anymore grief, call them a 'tracer'!!!

Seriously, though, I did remove admin rights from people that had been using admin rights for years and these people are very influential within our company and some within our industry, so I understand the hill you need to climb. It was more of a mindset than anything else and then soon realised that they didn't actually need it. It's like taking away the packaging from a baby, you may have it now and it might be fun to chew on, but go any further and you are going to suffer so I'm going to take it away from you before it's too late.

Sean

The problem with turning a blind eye to any person or group is that you
On 7/21/11 9:44 AM, "Thomas Larkin" <tlarki at kckps.org> wrote:
don't know what they're doing.

I've deployed nearly a dozen new Macs within the past couple of months to
developers here, some of which are newly hired contractors. Not that I
like it but our standard policy has been to allow them admin privileges
because they need access to more than a standard user on their machines. I
personally give each one a speech explaining that administrator privileges
do not mean they are allowed to purchase and install their own software.
Open source is fine as long as it falls under the project they're working
on. I've had two ignore that.

We take software licensing very seriously here. If I don't at least
monitor what they're doing then they could be violating our company
policies or vendor license agreements. I've found some blatantly turn a
blind eye themselves to licensing or are completely ignorant of why it's
important. All in the name of "doing what I need to get my job done."

--

William Smith
Technical Analyst
Merrill Communications LLC
(651) 632-1492

Hahahaha @ call them a tracer....Luckily I was no drinking my coffee when I read that. Otherwise I would have spat it on my laptop.

I use extension attributes to detect admin rights on machines and then hand the report to the administrators of the buildings. They then punish the person for violating AUP. Then again I work in academia and we are a bit more authoritarian here than some places in the private sector.

-Tom

They are like 4 people, they write in house apps that run on Macs and PCs that are web based, mostly .NET stuff. I don't care what they do. My head boss oversees them personally. They also don't need our support. They do their own thing, we do ours. Their machines aren't even bound to the domain, nor do they have network accounts, they also don't have the casper client loaded on them. They are dev macs, and out of my jurisdiction. Which I am 100% OK with.

-Tom

For our Xcoding dev guys, yes we add them to the _developer group. This group is created when you install the developer tools. Developers should be added to this group to use Xcode.

http://developer.apple.com/library/mac/#documentation/darwin/reference/manpages/man1/DevToolsSecurity.1.html

We edit the sudoers file, if we see fit, at their request. We have a massive Linux infrastructure, so there is some familiarity for some of them that code across both Linux and Mac.

We also provide our dev team an easy method for using different versions of python, for example, without us having to touch the OS. So if they feel the need to use a different version to the version we have provided in the OS, then they can. We achieve this with variables in executable mount maps.

So we may have something like:

servername:/mnt/raid/${OSNAME}/${OS_VERSION}/${CPU}/

This way they can provide a version of python depending on the version of OS, Leopard, Lion, etc and on architecture. automount already understands OSNAME and CPU, but we provide the OS_VERSION in the autofs.conf file.

So a fedora12 box might end up in:

servername:/mnt/raid/Linux/Darwin/x86_64,

whist a snowleopard mac might end up in:

servername:/mnt/raid/Darwin/snowleopard/x86_64

Sean

Such a great visualization for why to remove existing admin privileges!

Sean
~~~~~~~~~
Sean Alexander
Desktop Analyst
Macintosh Services Delivery
Lockheed Martin - Enterprise Business Services
~~~~~~~~~

Well to be fair our artists are in charge of multi-million dollar projects and need their Adium… I mean photoshop brushes installed :D

Nice!

If it helps the way we presented to them was thus.

• If your machine breaks and we need to re-install it, anything you have installed yourself we know nothing about and you wont have it after the re-install. This also includes rolling out new versions of the OS or having to roll back as an OS update, for example, has a bug that wasn't caught in testing. • We have a deployment system, Casper, if you request something we can package it. If you are happy with it, then we will already have a package to easily push this to all relevant users in the background. This also means a re-install will be the same as when you last used the machine as we have all of the components. • We ourselves only use admin when it is essential to administer the machine. • By denying admin access, we are ensuring that you have minimum downtime when you have an issue. If you need to meet a deadline and you have a problem with your machine, we can have it working again in 20-30 mins as was. If we allow admin, we cannot say how long it will take to get you back to working as required and you may miss your deadline. • We are not doing this to be an arse! We are doing this to benefit you the user to have the best user experience and therefore look good to our clients. Clients are impressed when they see how quickly a company recovers from an issue. It embeds an excellent level of trust.

Sean

I agree whole heartedly. In all the years we've been supporting Mac OS X (now OS X), not one viable reason has ever been put on the table by any company for users needing admin rights.

But, since we can't win all these battles, we compromise and offer our clients options:

1. Support cost for Macs with one or more admin accounts is 150% of standard (increases annually). 2. Support for Macs with one or more admin accounts is limited to reimaging your Mac (charge back to dept for time/effort since involves data migration).

There are other options as well...each designed to drive home the impact having admin rights has to ROI. With the above, it's only a matter of time before the company starts to give in. And those rare users who will never give in, well, they cost the company more money for support.

Don

Sean Holden Sean.Holden at framestore.com

Sheer genius, although not quite so useful for in house I still love this!

Sean

Most of the chest thumping I'm seeing are people who do not support higher ed faculty.
On Jul 21, 2011, at 7:55 AM, Sean Holden wrote:

In most of higher-ed, there is a dual reporting structure: staff (generally the IT people) report up a staff chain, while faculty report to other faculty. Eventually somewhere there's a staff administrator who reports to some faculty member. Faculty can get almost anything they want by complaining up their tree, and in most cases it comes back down as a demand from someone who really can't be questioned, like a dean.

The end result is that for many department IT shops, supporting faculty members is like supporting a fleet of CEOs. Now some groups can be very rational about it, but many can't. I've found that it's better to just work with their "need" to have admin rights than it is to argue. Come up with recovery strategies that mitigate downtime. Your liver will thank you.

--Jim

Those higher-ed institutions and their faculty...I tell ya.

And I was going to reply to Tom's comment about developers having sense
about managing a system and I'd have to disagree with that being a
dangerous assumption. People who can write code don't necessarily have any
understanding about how to maintain a system properly.

Not to offend any developers out there with such a broad statement, I'm
not saying all of them, but I've experienced that a few times.

Craig E

Extremely true. Our devs here can code but are in fact rather remedial when it comes to computers in general.

--
Matt Lee, CCA/ACMT/ACPT/ACDT
Senior IT Analyst / Desktop Architecture Team / Apple S.M.E / JAMF Casper Administrator
Fox Networks Group