Robotics - GitHub Time

From this day forth, Thursday robotics meetings are 45 minutes longer than usual, for a total of more than two hours of robotic goodness. This enables me to run around like a crazy man searching for various tools for even longer.

One of the FLL (middle school robotics) coaches happened to drop by. She is a project manager somewhere and knows a lot about organizational efficiency. She talked to us for a while about what kinds of things would help us get our work done better. All our rooms are a huge mess, and we don't really have a plan currently. I was planning on reading the full rulebook and maybe creating a task list during today's meeting, but then other things happened.

Specifically, since the teams had been reshuffled, I needed to get the NXT renamed and the wireless router reconfigured. Those tasks were very easy to do, but then I got the urge to also configure the Samantha wireless module. I ran around the rooms to collect the appropriate cables and the motor controller, but soon ran into a problem: the wires were frayed and fused and generally in disrepair at the ends. I then ran around some more looking for scissors and wire strippers. I found scissors, but the only wire strippers around didn't actually strip wires. So, I made do with what I had:

I pulled a knife and cut the insulation from the wires. (Dramatization. I actually had to scrounge around for any sharp object and ended up settling with a replacement pocketknife blade slightly poking out of its packaging.) Then, I used the scissors to cut off the frayed bits (metal shavings everywhere!) and screwed the now-much-tidier ends into the motor controller, which was actually being used to convert between power cables instead of controlling motors.

For some reason, the Samantha module wouldn't power on even though the motor controller light did. I tried with a different Samantha module and a different Samantha cord, so the problem must be with the battery or motor controller. That will wait for another day.

Then, I helped to continue assembling the field. After acquiring a drill, it was very easy to remove the failed rivets and then rivet the Plexiglass to the correct brackets. (One person also managed to break the riveter itself, which was kind of exciting. Fortunately, the math teacher (and I have no idea why he was in the room) fixed it, but it acts a little different now.) We made a lot of progress, adding the Plexiglass, the upper crossbar, and the support pipes to the center assembly.

Finally, I talked with the other programmer on the team and we decided to use GitHub for managing the robot program source code. Since GitHub is offering lots of cool free stuff to people with .edu e-mail addresses, we will have a private repository there. I created that today, granted him access, and started looking around on GitHub. It seems like a pretty nice thing. I will soon install the Windows Git client on my school-issued laptop and get to writing some code.

Robotics - Team Reshuffle

Today, the coach of the robotics teams reported that he had talked with some of the other school administrators and decided to change the teams. They are now going to go with the original plan of having one super-team of experienced people and a team of the new people. This should maximize the productivity of the people who really know what they're doing while letting the new people discover what works and maybe find something the veterans wouldn't.

This arrangement does leave the newbies without a programmer (or somebody who can set up their WiFi router), so I imagine I'll be giving them some help in my downtime.

After the short team meeting where this was announced, I destroyed the my documentation about the old teams and created a new OneDrive share with a new team roster document. We fixed the rivet issues created last time employing the help of a drill. We also went to the hardware store and bought some longer rivets to avoid such problems in the future.

The construction of the field's center assembly is still not close to complete, but at least we removed all the failed rivets from the holes. Next time, we'll mount the clear plastic and hopefully the ball bucket.

Windows 10 Technical Preview: Live First Impressions

Yesterday, I spent a couple hours recording a live "first impressions" video of the Microsoft Windows 10 Technical Preview. Tonight, I got it all edited down to one hour and uploaded it to YouTube. (I had to verify my account via phone to publish such a huge video.)

Sit back, relax, and enjoy the adventure! Welcome to Windows 10.

Robotics - Building the Field

I actually did something useful and robotics-related at robotics today! The components for our field just arrived, so it's time to set it up. The teachers/coaches/mentors decided to purchase components for only half the field, which is passable (we don't need to host actual four-robot rounds in our testing field), but of course suboptimal. We'll deal with it, but it will be somewhat more difficult to test both robots at the same time; having both sides of the field available for that was really nice last year.

There are quite a few parts and lots of nuts and bolts. So far, we built the ramp and started the construction of the centerpiece. The ramp construction was made somewhat difficult by the lack of an appropriately-sized crate to place under the top piece to hold it up. We also don't seem to have the right size of 90-degree braces, nor can we understand what the documentation means when it says "flanger." (We even looked it up and there is nothing like that in any of the pieces!)

The build team has a barebones drive system together, which I imagine I'll be programming tomorrow.

Windows 10 Developer Preview Upcoming

Microsoft has apparently scratched off the name "Windows 9" from their marketing materials and is instead calling the next version of the Windows operating system "Windows 10." I was under the impression that the Developer Preview would be released today, but it seems like that will actually happen tomorrow; it was just the developer conference event that happened today. When the release actually happens, you'll be able to download it at the Windows Preview site.

I have purposefully avoided demonstrations of the OS because I want to do a "first impressions" video on it. Allegedly, it removes the Charms bar and the Start screen, instead bringing back the Start menu, now metro-ized. Also in the feature list was the ability to create virtual desktops (kind of like that Windows XP PowerToy, I guess), which is pretty awesome.

Until the release, you can read the Windows blog article about it. Look forward to my video on Windows 10!

AdminPrivative: Design Specification for Partially Trusted Software Installation Delegation on a Windows Domain

In some Windows enterprise environments, it may be useful to grant certain people the ability to help users install stuff on their computers (probably laptops) via over-the-shoulder elevation without making them full domain admins. I outlined a strategy for doing something like this yourself, but now I have a pretty interesting idea that I might start developing.

Let's suppose you have issued laptops to a bunch of people on the assumption that each one is owned by a specific user and that the domain account for its owner will essentially always be the logged-on user. Suppose also that your users run as non-administrators and aren't allowed to do administrative things to their laptops, because it's usually a good idea to set things up that way. But your users occasionally do need to install programs, and you don't have enough time to OTS-elevate them, so you appoint a few people to do that. Since these people are supposed to just be administrators for the purpose of installing software onto these machines, they shouldn't be allowed to the domain or anything scary like that.

One possible option is to use Group Policy (or some system preparation script at set-up time) to set that group of installation helpers to be local admin on each machine. This has the major disadvantage of, well, letting them be local admin on every machine. Especially in a domain where remote server administration services are operating, having local admin is a very powerful thing. A group of people who you may or may not trust has full access to everybody else's stuff.

I thought of something better.

Forget about giving the install helpers' domain accounts any privileges. In this system which I call AdminPrivative (a pun on "alpha privative" and also a fairly accurate description of what it does), local temporary accounts are created whenever a normal user requests a software installation. The activities of those accounts are monitored, analyzed, logged, and reported to the real domain administrator's archives. A sketch of the design specification follows.

An AdminPrivative system consists of the following:

• Windows domain infrastructure
• A single authentication server/service, running as domain admin
• Local service on each computer eligible for AdminPrivative elevation

The AdminPrivative central server is a program running as a full domain admin. It should be under the control of the real domain administrator, not the install helpers. (All the install helpers have no special privileges at the domain level.) Its job is to listen for network requests (maybe serve a web form to gather the data) from the install helpers and authenticate them and get the control request. It then uses RPC (probably through PsExec or Sc.exe) to spawn the AdminPrivative service on the target computer.

The connection to the controller could be made on the target computer, but that would require entering credentials in a possibly compromised workstation. This system is designed in such a way that authentication to the central server should be done on a computer under the control of an install helper.

The local service prompts the machine owner to allow or deny the account creation. If the owner OK's it, the service prompts the owner for their domain password, checks it with Directory Services Account Management, and creates a local admin account. This account is added to the "Deny access to this computer from the network" list (using NTRights.exe) to prevent remote tampering. If the owner denies it (i.e. it was unsolicited), the local service tells the controller, which screams loudly into the e-mail box of the domain admin.

At this point, the local service tells the server that the account creation was successful, hands over the password to the install helper, makes a note of the time, and starts using WMI to monitor process creation. The server sends the temporary account's password to the install helper, who walks over to the laptop to perform an OTS elevation. The installer runs to completion, and after a few minutes, the local service destroys the temporary account and any processes laying around that it owns. It sends the log of processes created using that admin account to the controller, which generates a report of the entire transaction and sends it to the domain admin. If any issues are encountered (e.g. the local service stops responding), the controller complains to the domain admin.

The purpose of this entire system is not to try to stop the install helpers from doing bad things to the computers after they are granted control by the owner, but to log everything so that the domain admin can know what happened and who did what when.

Developing this would be a complex undertaking. I'm sure it will be an adventure!

How to Stop Windows Group Policy Refreshing

Now that you are able to override the domain Group Policy locally, you might have found that it occasionally gets reset, especially after a reboot. Windows can apparently detect when the policy cache is out of sync with the domain and will attempt to resync it, destroying local customizations.

Fortunately, this can be disabled. We can do so by revoking the system's privilege to modify those registry keys. Fire up RegEdit as admin and go to:

????\Software\Microsoft\Windows\CurrentVersion\Policies

The "????" should be HKEY_LOCAL_MACHINE if the annoying Group Policy entries are Computer Configuration or HKEY_CURRENT_USER if the offending policies are in User Configuration.

Right-click the key in the left pane and choose Permissions. Notice that SYSTEM is allowed Full Control. Uncheck that box in the bottom pane, but make sure SYSTEM has Read access. If you deny read access to the SYSTEM (or remove its DACE), then it won't be able to even check whether you can do things and stuff will blow up.

Then, open up the Owner tab under Advanced and set the owner to the local Administrators group. This ensures that [1] any Group Policy-deployed script can't undo our changes and [2] you'll be able to more easily edit the settings if you choose to change the permissions again.

OK out of all the dialogs and close RegEdit. Congratulations, you are now invincible to Group Policy.