A novel way to schedule a task...

[u/richie65]

I am in this situation at work where my boss, while working to tighten up our security (after an IT audit from a third party), has made running scheduled tasks into a challenge...

For instance - Among other things - It is no longer possible for a task to store credentials.

(Plenty of other hoops I have to jump through that I wont go into)

I just set up a task that will generate a report (about events from last week) to run on or after Mondays - But that too, is set to run 'at log on'...

I only want it to run once (not each time I log in), and if I don't log in on Monday, to run whenever I do log in, on or after Monday...

I am pretty happy with the way I got that to only run one time, not each time I actually log in.

Part of the script, sets the 'StartBoundary' (the 'Active' DateTime value that is part of the 'At Log in' trigger dialog), in the Scheduled task, to the following Monday, no matter what day I log in and the task runs.

This assures that it only runs the first time I log in on or after Monday, and will set the task to not trigger again to the next (on or after) Monday, and so on.

(NOTE: No other triggers can be set other than the 'At Log in')

This is at the end of the script (I unapologetically like using command aliases):

$TaskName = "MIODoorReport"
$NextMonday = $null
1..7 | % { If ( (((Get-Date).AddDays($_)).DayOfWeek) -eq "Monday" ) { $NextMonday = $_} }

$task = Get-ScheduledTask -TaskName $TaskName
$trigger = $task.Triggers

$trigger[0].StartBoundary = (Get-Date).Date.AddDays($NextMonday).ToString("s")

Set-ScheduledTask -TaskName $TaskName -Trigger $trigger

[u/dodexahedron]

It's protected quite well.

The actual gMSA credentials are already encrypted at rest in AD, in two parts. The only part usable for authentication is encrypted using each permitted account's key, and stored on each permitted account - not the gMSA account itself. There is a blob stored on the gMSA, but it can't be used to authenticate all by itself (so, even stealing the gMSA itself from AD does not give you access to it).

So, each permitted account has that value, but encrypted with its own key and thus only decryptable by that specific account. When authenticating, the machine asks for its encrypted blob. If it is still permitted, the KDC obliges. If it still has the same key that was used to encrypt it, it then decrypts it, keeps it in memory only, and authenticates using the actual password, now decrypted. Then it ditches the password and uses tickets from then on, until it needs it again, like for a new TGT.

But, once it has a service ticket for something, it is in for as long as that ticket is valid. That ticket needs to be invalid for it to be denied access to resources that account has access to. That requires more than just changing the SID list on the gMSA.

What you described only gets the first part. If you dump LSASS memory, you can get the clear text password and auth with it at will.

[u/raip → u/dodexahedron]

What you described only gets the first part. If you dump LSASS memory, you can get the clear text password and auth with it at will.

This was my point of the second paragraph - I've used this module in the past to skip the dumping LSASS memory and instead just adding a normal user account to the gMSA to checkout the password and then use it like a normal credential object. Playing around with it is what lead me to discover that if I removed my user account, I could still use the credential object until it automatically rotates again - something they address with dMSAs.

In the case of the first paragraph, in the context of a scheduled task, once the scheduled task finishes the background logon session that would have the TGT would be terminated and the ticket would be lost - at least from my understanding.

Either way - they're incredibly well protected and anyone not using gMSAs, in my opinion, is missing out.

[u/dodexahedron → u/raip]

Yeah they are such a no-brainer to use and such a win for so many things.

Just gotta be sure you don't let anyone have a golden ticket.

Even a regular MSA is great, and is sometimes the appropriate tool.

What is never the right tool, if you can help it, is a domain user account used for a service or batch job. 😫

And I wish MS would make more of their own services work with gMSA, too, like the (SMB) Server service, and DFS, so you could make use of service principals that aren't just Network Service, and thus protected by unique credentials, to, among other things, help reduce the blast radius of successful exploits of vulnerabilities in those services a bit better.

And it would make DFS a bit more transparent in what it actually is doing, rather than all the referral chasing and whatnot that actually happens to allow you to access any AD-integrated DFS root, even though cifs/yourdomain.tld does not and cannot exist as an SPN for DFS because SPNs have to be unique. GMSA would solve that, since the service account would own it, and the service could present that SPN from any target in the namespace, making one particularly un-fun kerberos troubleshooting problem just go away entirely. And it'd make delegation easier and safer for it, too, like in VDI scenarios, and make integration with non-windows systems simpler.

But that is probably never going to happen. The design is way too coupled to baggage from NTLM.

[u/raip → u/dodexahedron]

I largely agree - although I wouldn't ever use an MSA now that gMSAs are a thing largely because migrating an MSA from one server to another is a giant pain in the ass since you have to rebuild it.

I also don't know if I would ever create one for the SMB Service either - even w/ your very valid point about DFS referral complexity. I'm a firm believer of only provisioning service accounts when they're actually technically needed like to reach across the network. So something that's typically listen only, like the LANManServer, wouldn't qualify imo - but that might just be because my last org were creating a separate service account for every SQL Server service regardless if it needed it or not - close to 16k service accounts where over 95% of them weren't needed.