Bypassing Authentication?

[agerstein]

I just setup a G5 that's got one local admin account and authenticates to Active Directory for network accounts. Configured Retro for initial setup and it's fine, but I don't want to be the one that's in charge of the backups - it's going to be the local group of users in charge of that.

 

Because of this, I don't want Retro to "always require authentication" on startup - otherwise, they will have the local admin password, and that's just not going to happen.

 

I logged into my LAN account and set Retro to not require the authentication. Log out, log in as me again, and it works. So I then copy my Retro preference file to the computers /System/Library/User Template/English.lproj/Library/Preferences folder, which would mean that anyone who logs in after that would have this preference in their user account, and when Retro launches for them, it should see that it doesn't need to authenticate. In theory.

 

When I had a user log in, it didn't happen.

 

What am I doing wrong? Is there a different file that I need to get? Is there a way to have network users able to launch and configure Retro?

[CallMeDave]

Quote:

---

So I then copy my Retro preference file to the computers /System/Library/User Template/English.lproj/Library/Preferences folder, which would mean that anyone who logs in after that would have this preference in their user account, and when Retro launches for them, it should see that it doesn't need to authenticate. In theory.

 

---

 

Sounds as if your theory was based on the belief that Retrospect's authentication scheme is based on a simple preference file.

 

For an application that runs as root, that would be a pretty nasty security hole.

 

You can't move or modify the Retrospect application without resetting the authentication requirements to the default of needing a password. And you can't provide authentication authorization by pushing a file from a different machine.

 

Considering that Retrospect has the ability to read/write/erase every single file on a host machine, and if you are using Clients it has the abililty to do the same to every file on any connected Client, the idea that you'd give this sort of power to a user who wasn't trusted with an administrator account password seems a bit shortsighted.

 

There are probably some slick unix ways to modify a local account so that it can authenticate Retrospect, but be limited to the other stuff it could do in the Finder. Maybe some other readers can offer suggestions.

 

Dave

[agerstein]

I hadn't really considered the whole read/write/erase thing - good point. This machine is just going to be backing itself up, so if the users screw it up, they'd be screwing themselves - since they've already had problems with missing files, I think they're going to be erring on the side of caution.

 

Hopefully someone else will chime in with some ideas....

[CallMeDave]

Quote:

---

This machine is just going to be backing itself up, so if the users screw it up, they'd be screwing themselves

 

---

 

Then why not create an administrative account in the local NetInfo domain and let them use that for Retrospect authentication? They can still log into the Finder with their AD credentials, and the admin account wouldn't give them any privileges outside of this local box.

[agerstein]

The problem is that the end user, unless they are me, should never ever ever ever ever EVER have administrative privs on this box. It's a graphic design workstation that's used by student workers. We normally only assign a local admin (i.e. granting local admin priveleges for a network user) for faculty. They are students, so the policy is quite clear - no admin access, period.

 

It sounds like we might have to rework the plans....