Task.Definition.Principal.Account is null if in the UserId property of the task XML, is set in plain text, instead of SID

[onthegoldenpath]

I need to get a task' associated principal, which is set in 'When running the task use the following user account'. However, on some machines, the UserId in the task's XML is represented by Sid:

<Principal id="Author">
      <RunLevel>HighestAvailable</RunLevel>
      <UserId>S-1-5-21-2025382838-34760544-43243242434-1106</UserId>
      <LogonType>Password</LogonType>
</Principal>

In which case this works fine and I can retrieve the account, but on other machines the UserId is represented in plain text:

<Principal id="Author">
      <RunLevel>HighestAvailable</RunLevel>
      <UserId>Domain\User</UserId>
      <LogonType>Password</LogonType>
</Principal>

In which case Task.Definition.Principal.Account returns null

[dahall]

@msmilkoff: Can you tell me the parameters you are using for the TaskService constructor or if you are using TaskService.Instance? If this is using V2 of the Windows COM types, then I have no control over how the XML is read. It is done by Microsoft's underlying implementation. If this is V1 (for systems prior to Windows Vista), then I can address it as I wrote a compatible XML parser. I have never, in 15 years, seen the XML with anything except the SID, so this is very interesting to me.

[onthegoldenpath]

This happens on Windows Server but I do not know the version unfortunately. This is how I retrieve the task: Note: The task is created via Windows Task Scheduler, not via code.

 using (var taskService = new TaskService())
 {
     var ldapTask = taskService
            .FindAllTasks(t => t.Name.IndexOf(taskName, StringComparison.OrdinalIgnoreCase) >= 0)
            .FirstOrDefault();

      string taskOwner = ldapTask.Definition.Principal?.Account;
}

I can work around this by getting the task XML via ldapTask.Xml, parsing it and if the UserIdis not in SID I can just get the text value. Can this not be done when the Principal.Account is set?

[dahall]

Thanks for your workaround. It helped me have an idea as to how to prevent even though this is really Microsoft's library's problem. I'll look into it and let you know what I find.

[dahall]

I have a build that may fix your problem. Attached is a pre-release version of the NuGet package (zipped). Let me know if this works. TaskScheduler.2.8.16.nupkg.zip

[onthegoldenpath]

Thanks. It may take a couple of days to properly test since it has to go to a beta user's machine.

[karthimahendran]

Hi dahall I want task names whose runs with a specific user. If in case it has SID in the "USERID" I cant retrieve the task.

I need to fetch the task.Definition.Principal corresponding to the SID. If the "USERID" is SID then if i fetched task.Definition.Principal, it should be "DomainName\UserName"

Above Package is as I tested it return "\" in the task.Definition.Principal.

Kindly looking forward

[onthegoldenpath]

@dahall My logs confirm that this build resolved the issue. It occurs for multiple Users, all of them running Windows Server 2012 R2 Standard [6.3.9600]. Closing.

[dahall]

@karthimahendran Use the Account property. It will always return the username.

@msmilkoff I'm glad this fixed your problem. I'll publish 2.8.16 today with the fix.

[Gwindalmir]

I came across this issue when looking into an issue I have with Author not being set, as described in #659. I just wanted to comment that every task I create with this library on Windows 7 connected to AD uses the DOMAIN\User syntax in the task principal information, which is confirmed when exporting.

This doesn't fix the registration info author being null, I'd hoped it was related. It also doesn't fix new tasks being created with the DOMAIN\Username principal either. Though it sounds like that might be a Microsoft bug?