Dwarfsoft [GPA]

Recently I have been working on some rather complicated projects preparing our SOE to move from Novell eDirectory to an Active Directory environment. One of the packages I built was required to run periodically and so I set up a Scheduled Task to accomplish this. Rather than introduce a security risk by creating a new Administrator Account I just created the scheduled task to run as the local SYSTEM account. It turns out that the SYSTEM account does not have as much access as I required, especially when managing user registry hives.

After quite some time looking in to how to achieve my goal I came up with a rather simple, yet ultimately hacky, solution. Give the SYSTEM Account Administrative Privileges.

(continue reading…)

As promised, here are the scripts required for the Pre-staging of Domain User Profiles on the local machine. The first thing we need to do is Enumerate all the Local User Accounts.

Function StageAllUsers(DomainFQDN, strDomain)
   ' Enumerate all users that are Local and not built in accounts.
   strComputer = "."
   Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
   'Enumerate users where the User Domain is the Local Machine
   Set colItems = objWMIService.ExecQuery _
                  ("Select * from Win32_UserAccount " & _
                   "Where Domain = '" & GetComputerName & "' " & _
                   "And Disabled = FALSE And Name <> 'Administrator'")
   ' Stage each user
   For Each objItem In colItems
      ' Ensure the account actually has a profile (otherwise we can ignore it)
      If GetLocalUserProfile(objItem.Name) <> "" Then
         ret = StageUser(objItem.Name, DomainFQDN, strDomain)
      End If
   Next
End Function

The functions called here are GetComputerName, which returns the name of the local machine, and the other important ones are GetLocalUserProfile and Stage User. The first we can check is GetLocalUserProfile. (continue reading…)

Well, I have been very slack in that I haven’t updated with my Group Policy investigations or the eDirectory VBScript classes I was working on, but what I have been involved in recently is working on Migrating Workstations from Novell eDirectory to Active Directory.

In this process I have come across an array of options in migrating accounts from a Local User account to Domain User account and transferring the profiles across to keep the user “look and feel” that they are accustomed to.

One problem: In this scenario it makes for a very manual rollback strategy, no matter how much scripting and automation is involved in the migration process. This boils down to Novells implementation of “Dynamic Local User” which effectively creates a Local User Account that is not really bound to a User Account in eDirectory for Authentication or mapping purposes (which you can see if you look at the account SIDs).

(continue reading…)