Using LAPS

[Dave Lum]

Question: Who would be using the LAPS credentials, and if more than one person has access to look up the LAPS password how do you prove who used it?

LAPS doesn’t seem like a suitable way to do anything other than to log into a machine that has lost its domain link.

Yes I am new to LAPS being used for anything other than my previous comment.

Dave

 

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Kurt Buff
Sent: Wednesday, February 23, 2022 3:12 PM
To: ntsys...@googlegroups.com
Subject: Re: [ntsysadmin] RE: Server OU structure advice

 

- Get LAPS going on the servers

- Divide into departmental OUs as required.

- Deny login on those machines for regular (non-privileged) domain accounts (put the non-privileged accounts for the departmental admins into a group and use a GPO to deny login)

- Set up secondary/tertiary domain accounts for relevant admin staff on the servers, and make those secondary/tertiary local admins using Group Policy Preferences

- Deny Domain/Enterprise/Schema Admins login to those (or any other non-tier 0 servers - or only allow DAs logins to DCs and other tier 0 computers/systems)

 

Kurt

 

On Wed, Feb 23, 2022 at 3:37 PM 'Dave Lum' via ntsysadmin <ntsys...@googlegroups.com> wrote:

Many many ways to skin this cat. For admin perms on servers, we do the following:

Servers not in a particular group:  LocalAdmin-on-<servername>
Servers in any kind of group (say, SQL servers): LocalAdmin-SQLServers (server names are listed in the notes of AD, unless a GPO is used then it’s self-documenting).
Some people only need RDP, so there’s more groups: RDPAccess-SQLServers , or RDPAccess-AllServers (for Sysadmins not needing to use their DA acct, for example)

The appropriate group is the assigned as appropriate to the servers (can be done directly, or via GPO using restricted groups setting)

 

Users are then added to the necessary group. In our case we have team-level AD groups, so TEAM-SQL has SQL DBA’s in it and IS A MEMBER OF LocalAdmin-SQLservers.  New DBA? Add him to TEAM-SQL and they have all the perms they need without vising each server or “localadmin-<>” (or other) group.

 

My goal to be able to look at a users or a team membership and I know where and what access they have just by looking at which groups they’re a member of.

 

For us OU’s are laid out more for GPO and delegation of objects in the OU’s, not necessarily “if in this OU, SQL admins have admin perms”.  I tried to type out our example but it got too long to explain well J

It’s a bit of trial and error for your own org, and don’t be afraid to re-architect a little to fit changing needs as what works for a company of 100 and one admin might not scale to the company ten years later when there’s many admins with different specialties. I’ve seen brilliant “best guess following best practice” AD designs that were effectively revamped after a few years of operation.

 

FWIW,YMMV, etc.

 

Dave

 

From: 'Perisa, Nik' via ntsysadmin <ntsys...@googlegroups.com>
Sent: Monday, February 21, 2022 4:44 PM
To: ntsys...@googlegroups.com
Subject: [ntsysadmin] Server OU structure advice

 

looking for some advice or inspiration

 

currently where i am at, they have a server OU structure broken down by department and looks like the OUs are there to make things look neat and tidy and really provide any real purpose. Its a bit of a mess...

 

They want to have the server OU structure to be based on server function (SQL, APP, RDP etc...)

 

We also want to be able to set it so that users from the various teams have administrative access to their server with their admin accounts. The issue is that there may be overlap in terms of which servers they need access to and  also not need access to. So i'm a bit unsure how to configure the security groups to cater for this. I also need to work out the best way to apply a GPO to cater for this requirement...

 

 

Anyone have any recommendations? We basically have an infrastructure team that looks after the whole server fleet, but the other teams need to be able to admin their own servers essentially.

 

Public

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/2693737ea35843298fde6e6b2b43f893%40cgi.com.

Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender with a copy to compl...@ochin.org, delete this email and destroy all copies.

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CO1PR17MB5308EA5101F514D753F4372EDD3C9%40CO1PR17MB5308.namprd17.prod.outlook.com.

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CADy1Ce7BpzQv63Jk2uVRgJ5e-Kv1xfZ9FozyFtictwd%2BcWFTGA%40mail.gmail.com.

Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender with a copy to compl...@ochin.org, delete this email and destroy all copies.

[Eric W]

At my org, you need to enter your ad admin info to pull the password. To the best of my knowledge this is all logged. 

Sent from Der Isenphonen

On Feb 23, 2022, at 6:45 PM, 'Dave Lum' via ntsysadmin <ntsys...@googlegroups.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CO1PR17MB5308DEA48FBA1BB54B4536B4DD3C9%40CO1PR17MB5308.namprd17.prod.outlook.com.

[Kurt Buff]

For RDP: eventvwr.msc on target machine -->> Applications and Services Logs > Microsoft > Windows > TerminalServices-LocalSessionManager > Operational

Event IDs 21,22,25

But, we use Bomgar, which has good logging - and most PAMs (Thycotic, CyberArk, etc.) will track that too.

Kurt

Kurt

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CO1PR17MB5308DEA48FBA1BB54B4536B4DD3C9%40CO1PR17MB5308.namprd17.prod.outlook.com.

[Markus Klocker]

Most of all we use LAPS for security reasons (make lateral movement harder).
To view the current admin password you have to delegate the rights to a set of well known people.
So if there is no trust in those people I think there is another problem at hand.
Even if a local admin password has been given out without need it will be changed on it's own by LAPS anyways.
In our case GPOs would do the rest in deleting all additional admins generated by whom ever.

    Markus

Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender with a copy to compl...@ochin.org, delete this email and destroy all copies. --

You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CO1PR17MB5308DEA48FBA1BB54B4536B4DD3C9%40CO1PR17MB5308.namprd17.prod.outlook.com.

[Kurt Buff]

BTW - here's an article that crystallised my thinking on using LAPS:

https://techcommunity.microsoft.com/t5/microsoft-security-baselines/remote-use-of-local-accounts-laps-changes-everything/ba-p/701083

Kurt

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CO1PR17MB5308DEA48FBA1BB54B4536B4DD3C9%40CO1PR17MB5308.namprd17.prod.outlook.com.

[Dave Lum]

But if you’re troubleshooting a compromised account this would make it much harder to know whose account it was – if you have three admins with access to the LAPS password it exponentially creates more work to hunt down whose it was, no?

Dave

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/d440c4ec-8b0f-9cac-2f3b-eb9f51057726%40univie.ac.at.

[Jim Kennedy]

 

Don’t fall into that trap. There is no perfect solution in every scenario for any problem. Is LAPS perfect, nope. But consider that if one of the LAPS controlled accounts is compromised it is only good on ONE computer. While that can be bad it is not as devastating as the scenarios you face with out LAPS, not even close.

 

And there is nothing much to hunt down, it will be one account on one machine that one of three people recently used. Ask them or look at the work tickets to see who just worked on that machine.

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CO1PR17MB5308EC68377FA54344522DA5DD3D9%40CO1PR17MB5308.namprd17.prod.outlook.com.

CAUTION: This email originated from outside of the organization. Do not click any links or open any attachments unless you trust the sender and know the content is safe.

[Ken Dibble]

Is this still practical when you have computers that are frequently not connected to the domain?

Thanks.

Ken Dibble
www.stic-cil.org

At 07:35 AM 2/24/2022, you wrote:

BTW - here's an article that crystallised my thinking on using LAPS:
https://techcommunity.microsoft.com/t5/microsoft-security-baselines/remote-use-of-local-accounts-laps-changes-everything/ba-p/701083

Kurt

On Wed, Feb 23, 2022 at 4:45 PM 'Dave Lum' via ntsysadmin < ntsys...@googlegroups.com> wrote:

Question: Who would be using the LAPS credentials, and if more than one person has access to look up the LAPS password how do you prove who used it?

LAPS doesn’t seem like a suitable way to do anything other than to log into a machine that has lost its domain link.

Yes I am new to LAPS being used for anything other than my previous comment.

Dave

Â

From: ntsys...@googlegroups.com < ntsys...@googlegroups.com> On Behalf Of Kurt Buff

Sent: Wednesday, February 23, 2022 3:12 PM

To: ntsys...@googlegroups.com

Subject: Re: [ntsysadmin] RE: Server OU structure advice

Â

- Get LAPS going on the servers

- Divide into departmental OUs as required.

- Deny login on those machines for regular (non-privileged) domain accounts (put the non-privileged accounts for the departmental admins into a group and use a GPO to deny login)

- Set up secondary/tertiary domain accounts for relevant admin staff on the servers, and make those secondary/tertiary local admins using Group Policy Preferences

- Deny Domain/Enterprise/Schema Admins login to those (or any other non-tier 0 servers - or only allow DAs logins to DCs and other tier 0 computers/systems)

Â

Kurt

Â

On Wed, Feb 23, 2022 at 3:37 PM 'Dave Lum' via ntsysadmin < ntsys...@googlegroups.com> wrote:

Many many ways to skin this cat. For admin perms on servers, we do the following:

Servers not in a particular group: Â LocalAdmin-on-<servername>

Servers in any kind of group (say, SQL servers): LocalAdmin-SQLServers (server names are listed in the notes of AD, unless a GPO is used then it’s self-documenting).

Some people only need RDP, so there’s more groups: RDPAccess-SQLServers , or RDPAccess-AllServers (for Sysadmins not needing to use their DA acct, for example)

The appropriate group is the assigned as appropriate to the servers (can be done directly, or via GPO using restricted groups setting)

Â

Users are then added to the necessary group. In our case we have team-level AD groups, so TEAM-SQL has SQL DBA’s in it and IS A MEMBER OF LocalAdmin-SQLservers.  New DBA? Add him to TEAM-SQL and they have all the perms they need without vising each server or “localadmin-<>†(or other) group.

Â

My goal to be able to look at a users or a team membership and I know where and what access they have just by looking at which groups they’re a member of.

Â

For us OU’s are laid out more for GPO and delegation of objects in the OU’s, not necessarily “if in this OU, SQL admins have admin perms†.  I tried to type out our example but it got too long to explain well J

It’s a bit of trial and error for your own org, and don’t be afraid to re-architect a little to fit changing needs as what works for a company of 100 and one admin might not scale to the company ten years later when there’s many admins with different specialties. I’ve seen brilliant “best guess following best practice†AD designs that were effectively revamped after a few years of operation.

Â

FWIW,YMMV, etc.

Â

Dave

Â

From: 'Perisa, Nik' via ntsysadmin < ntsys...@googlegroups.com>

Sent: Monday, February 21, 2022 4:44 PM

To: ntsys...@googlegroups.com

Subject: [ntsysadmin] Server OU structure advice

Â

looking for some advice or inspiration

Â

currently where i am at, they have a server OU structure broken down by department and looks like the OUs are there to make things look neat and tidy and really provide any real purpose. Its a bit of a mess...

Â

They want to have the server OU structure to be based on server function (SQL, APP, RDP etc...)

Â

We also want to be able to set it so that users from the various teams have administrative access to their server with their admin accounts. The issue is that there may be overlap in terms of which servers they need access to and  also not need access to. So i'm a bit unsure how to configure the security groups to cater for this. I also need to work out the best way to apply a GPO to cater for this requirement...

Â

Â

Anyone have any recommendations? We basically have an infrastructure team that looks after the whole server fleet, but the other teams need to be able to admin their own servers essentially.

Â

Public

--

You received this message because you are subscribed to the Google Groups "ntsysadmin" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/2693737ea35843298fde6e6b2b43f893%40cgi.com .

Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender with a copy to compl...@ochin.org, delete this email and destroy all copies.

--

You received this message because you are subscribed to the Google Groups "ntsysadmin" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CO1PR17MB5308EA5101F514D753F4372EDD3C9%40CO1PR17MB5308.namprd17.prod.outlook.com .

[Dave Lum]

Thanks, this was the thinking I was looking for as I figured I was missing something.

I need to be able to answer these things when my team asks *me* questions about implementing it J

 

Dave

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/BN8PR11MB38107610EDE0B6AC0CAF7FFCF63D9%40BN8PR11MB3810.namprd11.prod.outlook.com.

[Kurt Buff]

Yes, absolutely.

The LAPS password will change at the interval which you set - but only if it can contact a domain controller. If the machine can't contact a DC for an extended period of time, then the password doesn't change.

Kurt

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/6217afd3.1c69fb81.82986.ea78SMTPIN_ADDED_MISSING%40gmr-mx.google.com.

[Kurt Buff]

No, it doesn't increase complexity - it simplifies.

As noted, the event log records the IP address of an RDP connection, which should immediately connect back to the workstation/jumpbox that initiated the connection - of course this implies that those workstations/jumpboxes are not shared and don't change addresses frequently.

The logs of other management tools should do the same or better.

Kurt

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CO1PR17MB5308EC68377FA54344522DA5DD3D9%40CO1PR17MB5308.namprd17.prod.outlook.com.

[Melvin Backus]

Nothing I can really add to that except a confirmation.

 

This absolutely works as advertised. I just had one this morning that had been off the network for months. The LAPS password had expired in November but still worked just fine, then after it got reconnected it got updated and changed.

 

--
There are 10 kinds of people in the world...
         those who understand binary and those who don't.

 

¯\_(ツ)_/¯

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CADy1Ce6DXtEeDDEFNo8mqD96JHmbTZqwdGfh28HK-up8jUYHeQ%40mail.gmail.com.

[Mayo, Bill]

Agree with all about LAPS being a good thing. One issue we have encountered in a few cases is where we have had to restore a VM from backup to look at some setting. In those scenarios, we isolate the machine (no network connectivity) to prevent issues with the currently running machine. Because it isn’t connected to the network, we can’t log in with domain accounts (excepting cached logons in some scenarios). If LAPS has since changed the password, it makes getting logged into the machine challenging. I would love to hear how folks are handling that scenario.

.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/BN8PR11MB38107610EDE0B6AC0CAF7FFCF63D9%40BN8PR11MB3810.namprd11.prod.outlook.com.

[Michael Kurzdorfer]

If the LAPS password is no longer available (due to OS restoral), you can use Microsoft Diagnostics and Recovery Toolset (DART) (https://docs.microsoft.com/en-us/microsoft-desktop-optimization-pack/dart-v10/overview-of-the-tools-in-dart-10). This is part of the Microsoft Desktop Optimization Pack (MDOP).  You do need a software assurance agreement to use it.  There are several utilities, however, the one specific to this thread is the locksmith utility allowing you to reset the local admin password.  It is also Bitlocker aware and you can safely unlock the volume to change the password or make other repairs.  This has definitely saved our bacon more than once.

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/22dc5bf09f0c4adb81e74f0477b2ca84%40pittcountync.gov.

[Philip Elder]

This method works great:

https://www.youtube.com/watch?v=Yxq4ifyr8_w

 

It can be used for getting control of a domain back too. BTDT.

 

Just make sure to remember to put things back.

 

This is the _why_ one should be BitLocker encrypting DCs.

 

Philip Elder MCTS

Senior Technical Architect

Microsoft High Availability MVP

E-mail: Phili...@mpecsinc.ca

Phone: +1 (780) 458-2028

Web: www.mpecsinc.com

Blog: blog.mpecsinc.com

Twitter: Twitter.com/MPECSInc

Skype: MPECSInc.

 

Please note: Although we may sometimes respond to email, text and phone calls instantly at all hours of the day, our regular business hours are 8:00 AM - 5:00 PM, Monday thru Friday.

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CA%2BZZigYymNJ19AExrVXzcprE5m541D50AcRn8SnOzxaic_GMCw%40mail.gmail.com.

[Ken Dibble]

Wait, what?

What is "OS restoral"? Does that mean that if the machine is controlled by LAPS and it gets hosed and I have to carry out a process to restore the OS that is somewhat short of reformatting and reinstalling, I won't be able to get into the local admin account without PAYING Microsoft something?

Ken Dibble
www.stic-cil.org

At 10:50 PM 2/24/2022, you wrote:

If the LAPS password is no longer available (due to OS restoral), you can use Microsoft Diagnostics and Recovery Toolset (DART) ( https://docs.microsoft.com/en-us/microsoft-desktop-optimization-pack/dart-v10/overview-of-the-tools-in-dart-10 ). This is part of the Microsoft Desktop Optimization Pack (MDOP).  You do need a software assurance agreement to use it.  There are several utilities, however, the one specific to this thread is the locksmith utility allowing you to reset the local admin password.  It is also Bitlocker aware and you can safely unlock the volume to change the password or make other repairs.  This has definitely saved our bacon more than once.

On Thu, Feb 24, 2022 at 1:19 PM Mayo, Bill < Bill...@pittcountync.gov> wrote:

Agree with all about LAPS being a good thing. One issue we have encountered in a few cases is where we have had to restore a VM from backup to look at some setting. In those scenarios, we isolate the machine (no network connectivity) to prevent issues with the currently running machine. Because it isn’t connected to the network, we can’t log in with domain accounts (excepting cached logons in some scenarios). If LAPS has since changed the password, it makes getting logged into the machine challenging. I would love to hear how folks are handling that scenario.

Â

Â

From: 'Jim Kennedy' via ntsysadmin < ntsys...@googlegroups.com>

Sent: Thursday, February 24, 2022 10:52 AM

To: ntsys...@googlegroups.com

Subject: RE: [ntsysadmin] Using LAPS

Â

Â

Don’t fall into that trap. There is no perfect solution in every scenario for any problem. Is LAPS perfect, nope. But consider that if one of the LAPS controlled accounts is compromised it is only good on ONE computer. While that can be bad it is not as devastating as the scenarios you face with out LAPS, not even close.

Â

And there is nothing much to hunt down, it will be one account on one machine that one of three people recently used. Ask them or look at the work tickets to see who just worked on that machine.

Â

From: 'Dave Lum' via ntsysadmin < ntsys...@googlegroups.com>

Sent: Thursday, February 24, 2022 10:41 AM

To: ntsys...@googlegroups.com

Subject: RE: [ntsysadmin] Using LAPS

Â

But if you’re troubleshooting a compromised account this would make it much harder to know whose account it was – if you have three admins with access to the LAPS password it exponentially creates more work to hunt down whose it was, no?

Dave

Â

From: ntsys...@googlegroups.com < ntsys...@googlegroups.com> On Behalf Of Markus Klocker

Sent: Thursday, February 24, 2022 12:21 AM

To: ntsys...@googlegroups.com

Subject: Re: [ntsysadmin] Using LAPS

Â

Most of all we use LAPS for security reasons (make lateral movement harder).

To view the current admin password you have to delegate the rights to a set of well known people.

So if there is no trust in those people I think there is another problem at hand.

Even if a local admin password has been given out without need it will be changed on it's own by LAPS anyways.

In our case GPOs would do the rest in deleting all additional admins generated by whom ever.

    Markus

On 24.02.2022 00:45, 'Dave Lum' via ntsysadmin wrote:

Question: Who would be using the LAPS credentials, and if more than one person has access to look up the LAPS password how do you prove who used it?

LAPS doesn’t seem like a suitable way to do anything other than to log into a machine that has lost its domain link.

Yes I am new to LAPS being used for anything other than my previous comment.

Dave

Â

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Kurt Buff

Sent: Wednesday, February 23, 2022 3:12 PM

To: ntsys...@googlegroups.com

Subject: Re: [ntsysadmin] RE: Server OU structure advice

Â

- Get LAPS going on the servers

- Divide into departmental OUs as required.

- Deny login on those machines for regular (non-privileged) domain accounts (put the non-privileged accounts for the departmental admins into a group and use a GPO to deny login)

- Set up secondary/tertiary domain accounts for relevant admin staff on the servers, and make those secondary/tertiary local admins using Group Policy Preferences

- Deny Domain/Enterprise/Schema Admins login to those (or any other non-tier 0 servers - or only allow DAs logins to DCs and other tier 0 computers/systems)

Â

Kurt

Â

On Wed, Feb 23, 2022 at 3:37 PM 'Dave Lum' via ntsysadmin < ntsys...@googlegroups.com> wrote:

Many many ways to skin this cat. For admin perms on servers, we do the following:

Servers not in a particular group: Â LocalAdmin-on-<servername>

Servers in any kind of group (say, SQL servers): LocalAdmin-SQLServers (server names are listed in the notes of AD, unless a GPO is used then it’s self-documenting).

Some people only need RDP, so there’s more groups: RDPAccess-SQLServers , or RDPAccess-AllServers (for Sysadmins not needing to use their DA acct, for example)

The appropriate group is the assigned as appropriate to the servers (can be done directly, or via GPO using restricted groups setting)

Â

Users are then added to the necessary group. In our case we have team-level AD groups, so TEAM-SQL has SQL DBA’s in it and IS A MEMBER OF LocalAdmin-SQLservers.  New DBA? Add him to TEAM-SQL and they have all the perms they need without vising each server or “localadmin-<>†(or other) group.

Â

My goal to be able to look at a users or a team membership and I know where and what access they have just by looking at which groups they’re a member of.

Â

For us OU’s are laid out more for GPO and delegation of objects in the OU’s, not necessarily “if in this OU, SQL admins have admin perms†.  I tried to type out our example but it got too long to explain well J

It’s a bit of trial and error for your own org, and don’t be afraid to re-architect a little to fit changing needs as what works for a company of 100 and one admin might not scale to the company ten years later when there’s many admins with different specialties. I’ve seen brilliant “best guess following best practice†AD designs that were effectively revamped after a few years of operation.

Â

FWIW,YMMV, etc.

Â

Dave

Â

From: 'Perisa, Nik' via ntsysadmin < ntsys...@googlegroups.com>

Sent: Monday, February 21, 2022 4:44 PM

To: ntsys...@googlegroups.com

Subject: [ntsysadmin] Server OU structure advice

Â

looking for some advice or inspiration

Â

currently where i am at, they have a server OU structure broken down by department and looks like the OUs are there to make things look neat and tidy and really provide any real purpose. Its a bit of a mess...

Â

They want to have the server OU structure to be based on server function (SQL, APP, RDP etc...)

Â

We also want to be able to set it so that users from the various teams have administrative access to their server with their admin accounts. The issue is that there may be overlap in terms of which servers they need access to and  also not need access to. So i'm a bit unsure how to configure the security groups to cater for this. I also need to work out the best way to apply a GPO to cater for this requirement...

Â

Â

Anyone have any recommendations? We basically have an infrastructure team that looks after the whole server fleet, but the other teams need to be able to admin their own servers essentially.

Â

Public

--

You received this message because you are subscribed to the Google Groups "ntsysadmin" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/2693737ea35843298fde6e6b2b43f893%40cgi.com .

Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender with a copy to compl...@ochin.org, delete this email and destroy all copies.

--

You received this message because you are subscribed to the Google Groups "ntsysadmin" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CO1PR17MB5308EA5101F514D753F4372EDD3C9%40CO1PR17MB5308.namprd17.prod.outlook.com .

[James Iversen]

Hey Ken,

Do you have "Recycle-bin" turned on?

I've never had too many issues retrieving LAPS passwords from a machine which was deleted from the DS...

There's ways to get info without buying DART, or some other thing to make management "easier"...

Have a great weekend!

James Iversen Network Systems Analyst IT Infrastructure     1899 Central Plaza East Edmeston, NY 13335
nycm.com

From:        "Ken Dibble" <ke...@stic-cil.org>
To:        ntsys...@googlegroups.com
Date:        02/25/2022 11:18 AM
Subject:        Re: [ntsysadmin] Using LAPS

Sent by:        ntsys...@googlegroups.com

---

---

ATTENTION: This email was sent from someone outside of NYCM.

---

.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/62190156.1c69fb81.b689e.86b7SMTPIN_ADDED_MISSING%40gmr-mx.google.com.









Join us on Facebook at www.facebook.com/NYCMInsurance.


***CONFIDENTIALITY NOTICE***

This email and any attachments to it are confidential and intended solely for the individual or entity to whom it is addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you have received this email in error, please contact the sender by reply email and destroy all copies of the original message.

[Michael B. Smith]

Pnordahl’s solution still works and it’s just as easy to use as dart.

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/OF19DAC2B9.5DBCFDBD-ON852587F4.005B53B0-852587F4.005B863D%40nycm.com.

[Ken Dibble]

Was that mentioned previously? I can't find it in this thread.

Thanks.

Ken

At 11:47 AM 2/25/2022, Michael B. Smith wrote:

Pnordahl’s solution still works and it’s just as easy to use as dart.

 

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of James Iversen
Sent: Friday, February 25, 2022 11:40 AM
To: ntsys...@googlegroups.com
Subject: Re: [ntsysadmin] Using LAPS

 

Hey Ken,

Do you have "Recycle-bin" turned on?

I've never had too many issues retrieving LAPS passwords from a machine which was deleted from the DS...

There's ways to get info without buying DART, or some other thing to make management "easier"...

Have a great weekend!

James Iversen
Network Systems Analyst
IT Infrastructure

 
 


1899 Central Plaza East
Edmeston, NY 13335


nycm.com







From:        "Ken Dibble" <ke...@stic-cil.org>
To:        ntsys...@googlegroups.com
Date:        02/25/2022 11:18 AM
Subject:        Re: [ntsysadmin] Using LAPS
Sent by:        ntsys...@googlegroups.com

---

ATTENTION: This email was sent from someone outside of NYCM.

---

 
Wait, what?

What is "OS restoral"? Does that mean that if the machine is controlled by LAPS and it gets hosed and I have to carry out a process to restore the OS that is somewhat short of reformatting and reinstalling, I won't be able to get into the local admin account without PAYING Microsoft something?

Ken Dibble
www.stic-cil.org

At 10:50 PM 2/24/2022, you wrote:

If the LAPS password is no longer available (due to OS restoral), you can use Microsoft Diagnostics and Recovery Toolset (DART) ( https://docs.microsoft.com/en-us/microsoft-desktop-optimization-pack/dart-v10/overview-of-the-tools-in-dart-10 ). This is part of the Microsoft Desktop Optimization Pack (MDOP).  You do need a software assurance agreement to use it.  There are several utilities, however, the one specific to this thread is the locksmith utility allowing you to reset the local admin password.  It is also Bitlocker aware and you can safely unlock the volume to change the password or make other repairs.  This has definitely saved our bacon more than once.

On Thu, Feb 24, 2022 at 1:19 PM Mayo, Bill < Bill...@pittcountync.gov> wrote:

Agree with all about LAPS being a good thing. One issue we have encountered in a few cases is where we have had to restore a VM from backup to look at some setting. In those scenarios, we isolate the machine (no network connectivity) to prevent issues with the currently running machine. Because it isn̢۪t connected to the netwetwork, we can̢۪t log in with domain accounts (exceptinging cached logons in some scenarios). If LAPS has since changed the password, it makes getting logged into the machine challenging. I would love to hear how folks are handling that scenario.

Â

Â

From: 'Jim Kennedy' via ntsysadmin < ntsys...@googlegroups.com>

Sent: Thursday, February 24, 2022 10:52 AM

To: ntsys...@googlegroups.com

Subject: RE: [ntsysadmin] Using LAPS

Â

Â

Don̢۪t fall into thathat trap. There is no perfect solution in every scenario for any problem. Is LAPS perfect, nope. But consider that if one of the LAPS controlled accounts is compromised it is only good on ONE computer. While that can be bad it is not as devastating as the scenarios you face with out LAPS, not even close.

Â

And there is nothing much to hunt down, it will be one account on one machine that one of three people recently used. Ask them or look at the work tickets to see who just worked on that machine.

Â

From: 'Dave Lum' via ntsysadmin < ntsys...@googlegroups.com>

Sent: Thursday, February 24, 2022 10:41 AM

To: ntsys...@googlegroups.com

Subject: RE: [ntsysadmin] Using LAPS

Â

But if you̢۪re trouboubleshooting a compromised account this would make it much harder to know whose account it was Рif you have three admins with access to the LAPPS password it exponentially creates more work to hunt down whose it was, no?

Dave

Â

From: ntsys...@googlegroups.com < ntsys...@googlegroups.com> On Behalf Of Markus Klocker

Sent: Thursday, February 24, 2022 12:21 AM

To: ntsys...@googlegroups.com

Subject: Re: [ntsysadmin] Using LAPS

Â

Most of all we use LAPS for security reasons (make lateral movement harder).

To view the current admin password you have to delegate the rights to a set of well known people.

So if there is no trust in those people I think there is another problem at hand.

Even if a local admin password has been given out without need it will be changed on it's own by LAPS anyways.

In our case GPOs would do the rest in deleting all additional admins generated by whom ever.

    Markus

On 24.02.2022 00:45, 'Dave Lum' via ntsysadmin wrote:



Question: Who would be using the LAPS credentials, and if more than one person has access to look up the LAPS password how do you prove who used it?

LAPS doesn̢۪t seem lm like a suitable way to do anything other than to log into a machine that has lost its domain link.

Yes I am new to LAPS being used for anything other than my previous comment.

Dave

Â

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Kurt Buff

Sent: Wednesday, February 23, 2022 3:12 PM

To: ntsys...@googlegroups.com

Subject: Re: [ntsysadmin] RE: Server OU structure advice

Â

- Get LAPS going on the servers

- Divide into departmental OUs as required.

- Deny login on those machines for regular (non-privileged) domain accounts (put the non-privileged accounts for the departmental admins into a group and use a GPO to deny login)

- Set up secondary/tertiary domain accounts for relevant admin staff on the servers, and make those secondary/tertiary local admins using Group Policy Preferences

- Deny Domain/Enterprise/Schema Admins login to those (or any other non-tier 0 servers - or only allow DAs logins to DCs and other tier 0 computers/systems)

Â

Kurt

[Michael B. Smith]

Probably not. I’ve been using it since WinNT, long before DART existed.

 

https://pogostick.net/~pnh/ntpasswd/

--

You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/62190a00.1c69fb81.37d00.059eSMTPIN_ADDED_MISSING%40gmr-mx.google.com.

[Jim Kennedy]

On the Volume Licensing Center the newest version is 2015. Is that correct?

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CA%2BZZigYymNJ19AExrVXzcprE5m541D50AcRn8SnOzxaic_GMCw%40mail.gmail.com.

[Philip Elder]

Yes.

 

MDOP has been discontinued as a Software Assurance grant. ☹

 

We still use the tools. DART is okay to have in a pinch (Utilman.EXE is our go-to) but Crash Analyzer is the best.

 

Philip Elder MCTS

Senior Technical Architect

Microsoft High Availability MVP

E-mail: Phili...@mpecsinc.ca

Phone: +1 (780) 458-2028

Web: www.mpecsinc.com

Blog: blog.mpecsinc.com

Twitter: Twitter.com/MPECSInc

Skype: MPECSInc.

 

Please note: Although we may sometimes respond to email, text and phone calls instantly at all hours of the day, our regular business hours are 8:00 AM - 5:00 PM, Monday thru Friday.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/BN8PR11MB38109821028E9CDE5470A399F63E9%40BN8PR11MB3810.namprd11.prod.outlook.com.

[Shawn K. Hall]

This is still very effective...as long as you're not using an encrypted file system/bitlocker.

-S

> [] []
> []
>
> []

> 1899 Central Plaza East
> Edmeston, NY 13335
>
>

> nycm.com <http://www.nycm.com/>

>
>
>
>
>
>
>
> From: "Ken Dibble" <ke...@stic-cil.org>
> To: ntsys...@googlegroups.com
> Date: 02/25/2022 11:18 AM
> Subject: Re: [ntsysadmin] Using LAPS
> Sent by: ntsys...@googlegroups.com
>
>
>
>
>
> ________________________________
>
> ATTENTION: This email was sent from someone outside of NYCM.
>
> ________________________________
>
>
> Wait, what?
>
> What is "OS restoral"? Does that mean that if the
> machine is controlled by LAPS and it gets hosed and I have to
> carry out a process to restore the OS that is somewhat short
> of reformatting and reinstalling, I won't be able to get into
> the local admin account without PAYING Microsoft something?
>
> Ken Dibble
> www.stic-cil.org
>

> <https://urldefense.com/v3/__http:/www.stic-cil.org/__;!!EepO9
> 1JVOnUi!jj2TQexPLbvIt-uWWzhYq1cCx-DeL-pmYOXj1GPSduMRRRN5aHd4X7
> 9j6mgevQ$>

> At 10:50 PM 2/24/2022, you wrote:
> If the LAPS password is no longer available (due to
> OS restoral), you can use Microsoft Diagnostics and Recovery
> Toolset (DART) (
> <https://docs.microsoft.com/en-us/microsoft-desktop-optimizati
> on-pack/dart-v10/overview-of-the-tools-in-dart-10>

> https://docs.microsoft.com/en-us/microsoft-desktop-optimizatio

> n-pack/dart-v10/overview-of-the-tools-in-dart-10 ). This is
> part of the Microsoft Desktop Optimization Pack (MDOP).Â
> You do need a software assurance agreement to use it.Â
> There are several utilities, however, the one specific to
> this thread is the locksmith utility allowing you to reset
> the local admin password. It is also Bitlocker aware and
> you can safely unlock the volume to change the password or
> make other repairs. This has definitely saved our bacon
> more than once.
>
> On Thu, Feb 24, 2022 at 1:19 PM Mayo, Bill <
> Bill...@pittcountync.gov

> <https://groups.google.com/d/msgid/ntsysadmin/62190a00.1c69fb8
> 1.37d00.059eSMTPIN_ADDED_MISSING%40gmr-mx.google.com?utm_mediu
m=email&utm_source=footer> .

>
> --
> You received this message because you are subscribed to the
> Google Groups "ntsysadmin" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to ntsysadmin+...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/ntsysadmin/3bc9d2beb9364af9b
> fad122e91f9fe1d%40smithcons.com
> <https://groups.google.com/d/msgid/ntsysadmin/3bc9d2beb9364af9
> bfad122e91f9fe1d%40smithcons.com?utm_medium=email&utm_source=footer> .
>
>