Partager via

LAPS and AD sizing considerations

  • Article

Recently, I got asked few times by people planning LAPS deployment about LAPS impact to their AD infrastructure - NTDS.dit size, replication, network bandwidth during GPO update. I always answered that LAPS impact will never be noticed because it's pretty small - and it's actually true. However, I thought it would be good to document here how small the LAPS deplyoment impact really is. So if you're interested, read further.

LAPS deployment impacts AD in the following major areas:

  • AD DB size: It stores data in AD database, so people expect AD database grow
  • Client - DC traffic during GPO update
  • AD Replication traffic: LAPS client updates data in AD DB, and updates need to be replicated

AD DB size

LAPS stores 2 pieces of information in AD:

  • Password: Stored as string, 1 byte per character (syntax of respective attribute is IA5 string)
  • Password expiration time: 64-bit number, stored as string (currently 18 chars), 1 byte per number

So LAPS deployment with default password parameters - password 12 chars long expiring once a month - is expected to store 30 bytes of data with computer account.

To validate this expectation, I took ma test AD instance and created 25K of computer accounts (via New-ADComputer cmdlet), and then populated LAPS attributes with real data - password generated with LAPS password generator and password expiration time in proper format. If the expectation is correct, then total increase of DB size shall be 25000 x 30 bytes = 750KB.

Size of AD DB size below:

  • Before creating 25K computer accounts: 32 MB
  • After creating 25K computer accounts: 262 MB
  • After populating password and expiration time: 262 MB

So no increase of AD DB size at all - AD allocates AD space in chunks, and was able to host data in whitespace allocated. Also, notice AD DB increase caused by creation of "empty" computer accounts: single computer account consumes almost 10KB of space.

As an additional test, I updated password to be 36 chars long on all 25K computer accounts. As a result, LAPS data now occuppied 54 bytes per computer account (18 bytes expiration timestamp + 36 bytes password). Resulting size of AD database after update: 262 MB - so no increase of DB size at all again!

So we may say that most environment will not see any impact on AD DB size at all - even in environment with 1M of LAPS-managed machines, expected impact on AD size would be less than 50MB - really small fraction of their current AD DB size.

Client - DC traffic

Client - DC traffic during GPO update consists of 2 basic components:

  • Download of registry.pol file from SYSVOL: .pol file contains LAPS-specific GPO settings
  • LDAP traffic caused by LAPS client: LAPS client always reads password expiration time from AD, and - if password expired - uploads new password and expiration time

Registry.pol file

If you created dedicated GPO for LAPS settings, you can see the size of registry.pol yourself. If should be something between 148 bytes (minimal size that contains only necessary setting) and 942 bytes (all policies specified; size of custom admin name 20 chars). When LAPS settings are configured in existing GPO, size of registry.pol file increases accordingly - up to 1KB based on amount of settings configured

GPO client downloads the file within existing SMB session, so not much overhead here. Also, when you created new GPO, there's few things that GPO clients does (reads gpt.ini for new GPO, checks GPO version, etc.) - but those things are not LAPS specific.

Overall, let's say that impact in this area is up to 1 KB of network traffic.

LDAP traffic

LAPS client creates own LDAP session with DC, and uses encryption and signing to protect data transferred. Note for those having RODC in their environment: LAPS client ALWAYS talks to writable DC, always ignoring RODC (details may be worth of dedicated article in the future)

During initial rollout, LAPS clients try to retrieve password expiration time, receive error that value is not there, and uploads new password and expiration timestamp

During normal operation, LAPS client just retrieves password expiration time from AD, sees that password did not expire and stops processing.

When password expires (or is reset by LAPS operator), LAPS client downloads password expiration time, and uploads new password and expiration time.

Below see the impact on network traffic for scenarios above (captured by Netmon and analyzed by PSCap tool):

  • Initial rollout:
    • Client -> DC: 10 frames, 2782 bytes
    • DC -> Client: 7 frames, 847 bytes
  • Normal operation, no password change:
    • Client -> DC: 6 frames, 2308 bytes
    • DC -> Client: 6 frames, 767 bytes
  • Normal operation, password change & upload:
    • Client -> DC: 8 frames, 2674 bytes
    • DC -> Client: 7 frames, 908 bytes

So overall, impact on network bandwidth caused by LDAP operations per LAPS client is up to 3KB of download and up to 1KB of upload. You can estimate impact to your environment just by multiplying these numbers by # of machines serviced by single DC.

Replication traffic

As shown above, 1 LAPS client typically stores less than 50 bytes in AD database. This data typically changes 1 x month, and needs to be replicated to other DCs in domain. By default, LAPS data is not replicated to GC.

Let's take the example we used for AD DB sizing impact estimation above - 25K LAPS managed machines - let's assume that all those machines are supported by 1 DC (in real environment, the number will likely be lower).

For intrasite replication, this means to replicate ~750KB of data, uncompressed, which is really nothing you should be worried about. Remember, data is changed during GPO update, and GPO framework itself adds some random delay, so as all machines do not contact DC at the same time, and the change will not happen at the same time, and data is likely to be replicated during different replication cycles.

For intersite replication, worst case is that you have scheduled replication quite infrequently, and all machines supported by single DC will change the password between 2 replication cycles of that DC. this means that DC needs to replicate ~750KB of data, compressed. For LAPS data, you can expect compression ratio ~50%, so amount of data that needs to be replicated cross-site is likely less than 400KB. Again, this is nothing to be worried about, and, most likely, in your environment, the amount of data for single replication cycle is expected to be much less.

Note: I tested compression ratio by putting passwords and password expiration timestamps to ascii encoded text file, and compressing via makecab utility to create a compressed archive (uses mszip compressing, the same as legacy AD replication). Size of archive was slightly less than 50% of original file size

For replication with RODC, the amount of data will be even less: password is not replicated to RODC in standard LAPS setup, so only information that is replicated to RODC, is password expiration timestamp (18 bytes per computer account)

Summary

Impact of LAPS deployment to AD infrastructure is really small, and in most environments, AD admins will not even see it.

Jiri

Comments

  • Anonymous
    September 28, 2016
    LAPS has disappeared off the Microsoft Download Center... Where can we get it now?
  • Anonymous
    November 13, 2016
    When I try to set the permissions I get:Set-AdmPwdComputerSelfPermission : The size limit was exceededis that the typical 2000 object limit? (I certainly hope not...)CheersAndre
  • Anonymous
    March 27, 2017
    We are experiencing computer object issues, where the password history is growing, and no space exists to create new password. Any advise on this or policy setting that could be set to overwrite passwords after X number?[Aaron Margosis] This doesn’t apply to LAPS – it sounds like you have a customized version that supports password history. Check the documentation that came with your implementation for information about managing password history.