Posts made by Brett

I have experienced a similar sounding issue with some workstations that were upgraded from Windows 7 to 10. There was a single file that was carried forward that caused the print spooler to fail. It was noted in the errors in either the Application or System log. All I had to do was delete that file, restart the PC, and it began working just fine. I believe it was from their tax software (CPA office). Might check into that.

Put the app/extension ID alone in the Chrome extension whitelist and blacklist policies. The $ID;$URL format, like you have in the OP, is only used in the Configure the list of force-installed apps and extensions policy.

FYI, rather than selectively blacklisting I choose to use * in the blacklist policy to deny all. I then explicitly allow certain apps/extensions in the whitelist policy. And finally there are a few of those allowed apps/extensions that I have force installed like uBlock Origin, LastPass, Chrome Legacy Browser Support, etc. It's worked well for me and the clients I manage.

I'm very much a Linux noob, so I don't know what command to use. But I'd just use a regular expression alone or perhaps in combination with some other command to get the desired text here. In Powershell I would use the -match operator and/or the Select-String cmdlet.

According to their blog you can still use chrome://apps. But that appears to be a touch only interface.

Does anyone know of an alternative that allows for searching your apps by typing?

@travisdh1 I'm right there with you.

I became used to it on my Chromebook, so I have the Chrome App Launcher mapped to my CapsLock key in Windows via AutoHotKey.

I found it rather convenient because I could hit CapsLock, type gm, hit Enter, and bam I'm in Gmail. It's like using Windows' start menu, just for Chrome apps. I probably have 10 of them or so - Gmail, Calendar, Drive, Keep, Photos, Play Music, Signal, Keeper, YouTube.

Oh well, guess I'll have to figure out the next easiest method to open those.

@Dashrender said:

@Brett said:

Also please note that you do not want LAPS to apply to domain controllers since they have no local accounts. It will change the domain's Administrator account password. I found that out while testing LAPS.

I still use it on servers, just not DCs.

Doh! it changes Domain Admin accounts - that's not cool. Though, I guess this means that your domain admin account name was the same as the local account? or are you talking specifically about the Administrator account?

I've changed the name of my Domain Administrator account so that's not an issue.

Yes, you're exactly right. So, as I'm sure you know but just to be clear, by default the built-in Administrator account is named Administrator on all Windows and Windows Server OSes. And when you upgrade a server to become a DC for the first time in an environment it converts that built-in Administrator account into the domain's Administrator account, and it's still named Administrator. (So suddenly you go from using ServerName\Administrator to the all-powerful NetBIOSDomainName\Administrator with the same password the first time you create a DC.)

LAPS by default changes the account named Administrator, whether it's just a local built-in account on a workstation or server or the domain account. So if you haven't changed LAPS away from the defaults and you haven't changed your built-in Administrator account (either on a workstation or on the DCs) it will change their password.

I like to leave the built-in Administrator accounts alone on the workstations. They're disabled by default and when you first install Windows it has you create an alternative local admin account anyway. So I figure there's some purpose behind that. Plus, I've read that even if you rename the built-in Administrator account it's trivial for attackers to find them b/c their SID is unique and stays the same no matter what the name is changed to. It's another example of how security through obscurity doesn't really work. So that's why I opt to leave them disabled and create an account named LocalAdmin instead and I change the LAPS policy to target these for password changes.

Regarding the built-in domain administrator account named Administrator, I generally leave it in the hands of my clients, as an in-case-of-emergency-use-this-account. But for everyday administration it's never touched. So I just don't apply the LAPS GPO to the DC OU to be absolutely sure, but by the fact that I have the LAPS policy changed to target accounts named LocalAdmin it shouldn't affect them anyway.

I hope that made sense!

Also please note that you do not want LAPS to apply to domain controllers since they have no local accounts. It will change the domain's Administrator account password. I found that out while testing LAPS.

I still use it on servers, just not DCs.

@Dashrender said:

@Brett said:

@JaredBusch said:

@Mike-Davis said:

@JaredBusch said:

As an outsourced IT Service Provider, we cannot be always available to clients to handle this need in as timely a fashion as needed at times (i.e. the owner says he needs his cat pics screensaver installed now).

The compromise we have come up with is a domain account that is added to the local administrators group in AD.

I'm in the boat and also use group policy to push a local admin account to the machines through group policy. If a machine (esp laptops) decides it doesn't want to log in to the domain, you can just log in with the local account and get it going.

Yeah, we push that LocalAdmin via GPO. It is not manually setup on the machines.

Consider changing this practice. I used to do it that way, too, but it's no longer considered secure and Microsoft won't even allow you to do it anymore in the newer versions of Windows Server in the GPPs.

So I read through the LAPS you linked to.. and I have to ask.. What's the difference between JB's creating a specific account and granting that account local admin and the fact that by default domain admin group is added to the local administrators group on every PC on the domain?

LAPS is more about the local admin account password being set the same on every machine, but JB's solution isn't the local admin account, it's a domain account that's granted local admin access.

I have done what LAPS is meant to replace - use GPO to set the local admin password to a specific password, and your point about it applying to more than just workstations is well received. I'm going to look into LAPS. Thanks.

I don't think I fully understood what Jared was saying.I replied to his line about pushing a "local admin" account via group policy without thoroughly looking at his earlier posts with the screenshots. I didn't realize he meant pushing a domain account named local admin.

What you don't want to do is create local accounts via GPPs because the passwords aren't stored securely. This is where LAPS helps because it gives a local account on each workstation a random password every so many days that's stored in AD. Also note that you can assign it to any account. For instance, I leave the builtin administrator account disabled but create a new local admin named "LocalAdmin" as part of the provisioning process. Then LAPS changes its password regularly for me.

But as far as pushing a domain user (or security group) into the workstations' local administrators group, I don't think there's anything wrong with that. My only word of caution would be to only use that account for workstation administration so that an attacker can't pass the hash into more significant systems.

Through a GPO I prevent the workstation admin security group from having logon rights to server systems and vice versa for the server admin security group. With PDQ Inventory and Deploy I use accounts that are restricted to logon as batch or service since there's no need for interactive logon.

It really all comes down to having only the rights that are necessary for the task.

I also wanted to add that I love Admin Arsenal's PDQ Inventory and Deploy. They aren't the cheapest software ever, but in my situation it works out well. Their licensing policy is per admin, so I'm free to use it at all my clients' offices as long as I'm the one using it. I do outsourced IT, so it's perfect.

At a few smaller locations that don't have a central server (or workstation they use as a server) I've setup chocolatey scripts and used Ninite, too. Both work well.

It's really cut down on the admin pop-ups caused by Adobe Reader, Adobe Flash, and Java.

When provisioning a new workstation there's obviously a need to use admin credentials a lot. But thereafter I find that if you can take care of these frequently updated pieces of software users rarely encounter admin UAC prompts.

@JaredBusch said:

@Mike-Davis said:

@JaredBusch said:

As an outsourced IT Service Provider, we cannot be always available to clients to handle this need in as timely a fashion as needed at times (i.e. the owner says he needs his cat pics screensaver installed now).

The compromise we have come up with is a domain account that is added to the local administrators group in AD.

I'm in the boat and also use group policy to push a local admin account to the machines through group policy. If a machine (esp laptops) decides it doesn't want to log in to the domain, you can just log in with the local account and get it going.

Yeah, we push that LocalAdmin via GPO. It is not manually setup on the machines.

Consider changing this practice. I used to do it that way, too, but it's no longer considered secure and Microsoft won't even allow you to do it anymore in the newer versions of Windows Server in the GPPs.

Account info disseminated this way isn't hard to find, I believe its in the SYSVOL folder somewhere, and once an attacker had it they could laterally jump from machine to machine with ease. This would be especially bad if that policy was applied to more than just workstations.

This doesn't produce the exact same results, but today you would want to use Microsoft's LAPS (Local Administrator Password Solution):
https://www.microsoft.com/en-us/download/details.aspx?id=46899
I've set it up several times now and it's really easy to use.

I'm sorry if you're already familiar with it, but I didn't want anyone to think your suggestion is a good practice these days.