Appreciate the comments, but they are not taking into account the scenario that affected my problem, as mine was different. In my case, it had nothing to do with 'admin' group itself, but rather how I had configured "Domain groups" and had omitted to explicitly add my Active Directory userID.
In all of the comments that were made in reply to my own, not a single one mentioned Active Directory or anything other than local accounts and groups. My case is not typical, so therefore your answers... while they would be correct in any other case, were incorrect in my case. Notice that in item #4 of my original comment that the domain was currently not available to validate my userID as being a domain member. I don't use local accounts at all, except for root, and that ID is only used for system maintenance prior to setting up CentrifyDC to join the system to Active Directory. Needless to say, if the userid is an active directory ID rather than local, then you can do whatever you want to the local groups config and it won't matter unless you explicitely add the UserID rather than the group that user is a member of. I've long since realized (since I posted that back in April) that I can simply setup my VPN connection from within the desktop environment for 'root', VPN into my home network where my domain controllers are located, at which point I can simply ssh as my Active Directory userID into 127.0.0.1 while the VPN connection is active to force an update of the cached credentials, and group cache. Essentially, mine was an issue where a remote group was inaccessible to allow proper validation of a local group that had the remote group nested as a member. Otherwise though, I'm aware of the other ideas posted here, and my end results were that I simply added my Active Directory UserName as an explicit entry in /etc/group to all appropriate groups also occupied by 'root' & "%Domain\ Admins". I haven't had a problem like this since then. I figured the issue had to do with a local group, and that any valid user account would need admin/sudo access in order to properly add any interfaces (ppp, vpn, etc), but it's a totally different scenario when you are using remote groups nested inside of local groups along with AD- auth, as opposed to local groups and local users explicitly. It basically adds a couple of dozen more pieces to the puzzle. :) Anyways, I hope this doesn't come off as trolling, as that's certainly not my intent. My intent is simply to show an alternate scenario where the same problem occurs for similar but different reasons. In the end, the results are the same, for the same reason, but the components of the problem slightly vary. Just to further complicate things, the installation on which I had dealt with this issue on is a "Sandisk 16GB USB stick", loaded with Ubuntu 12.04, that I use with an Acer Iconia Tab W500 (x86 tablet) so that I don't have to give up local disc-space to Ubuntu, which doesn't work quite perfectly with the touch-screen, hence why it's my secondary OS on that system rather than my primary. Fortunately, my builds on USB are basically identical to the builds I do on hard drives, only that I sacrifice creating a swap partition since the systems I use these on have no less than 2GB mem, so I don't really need a swap anyway because these are workstation builds that don't require a huge amount of resources. Anyways, thanks! :) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/964705 Title: System policy prevents modification of network settings for all users To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/964705/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
