Demystifying Managed Service Accounts

So this presentation is all about managed service accounts or also service accounts with the focus in this case of managed cl looking at the new stuff. So thanks for the sponsors of this event because without them it wouldn't be possible to do this. So, make sure to visit the the the stands of those um uh sponsors. A little bit about me, as already said, senior instant response lead. Um I've been working with identity for many many years, securing it, but also recovering it when things go bad. Think about attacks, think about ransomware, think about everything that can go wrong. And in this case, I'm more focused on the old stuff. Active Directory um wrote few scripts that have that are

being used by many many companies throughout the world. So if you have any feedback just let me know and I'll try to fix stuff as soon as possible. The evolution of service accounts. So since the stone age we have been using the so-called legacy service accounts for many years as insecure as you can imagine. And because of that, Microsoft came up with these so-called standalone managed service accounts. Improvement in security somewhat. Then again, there was still not much movement. Then Microsoft came up with the group managed service accounts, more flexibility, more servers or at least to use one account on multiple servers. But then again, although there was more adoption, not much happened because many

companies still use the old stuff because moving away is painful. It's reality. And because of that, Microsoft came up with Server 2025 delegated managed service accounts, which basically allowed you to, in summary, I'm going to talk a lot about it later on, allows you to keep using the old one, but let's say connect it to another account, which then becomes automatically managed, more security. But then again, when something new is developed, what are the catches? What are the things that can go wrong? And there are things that can go wrong. Let's have a look at manage or the legacy service accounts. Those things are all over the place. Think about services, schedule tasks, um, key tabs

everywhere. And it's just like your user account or an admin account. It's just a user account for specific purpose, a service. And because of that, it has a static password. That's one of the things where things already wrong. The password is static. Nobody likes to change the password on a service account because you have to touch the service account in act in active directory for example and probably also on many servers and because of that it means you have to have an maintenance window or outage or whatever things could go wrong or will go wrong. Most of the times those are configured with service principle names to let's call it define the service. So that's easily easily

lookup and it handles over uh TGS tickets RC4 support. Well, let's see what's going to happen in a month because if I'm not mistaken in a month or so, Microsoft has been changing quite a lot of stuff to move away from RC4 and suddenly the last few months from very quickly to AAS. I don't have a glass ball, but I'm really excited in what's going to happen in a month or all those systems that are going to break because of the sudden change of not being able to support AES for whatever reason. And those service accounts most of the time are overprivileged, too many permissions, maybe domain admin or something that is very near to domain admin. Application

owners having multiple accounts and because all those passwords al sorry, all those accounts need to be managed. I've seen it happen where a application owner has multiple accounts has an admin account has a user account and after performing a security assessment on the let's call it how passwords are being used that all those accounts have the same password compromise one you have all the others it's reality stuff happens naming conventions what is a so-called service account have you already defined a naming convention up front and are you sticking to it because if you don't, well, one of the problems with service accounts is first of all, how do you find them in active directory? What is a service account?

And even if you know already what a service account is in your AD, how the hell do you even know it's being used because those things are all over the place or could be all over the place. And if you don't have ownership and reertify the account from time to time, reertify means asking the owner, hey, do you still need this? Yes or no? If the answer is no, get rid of it. So, it's painful. And because it's so painful, this is what attackers love. Password never expires because the password is static, overprivileged, weak passwords. And because of that, the best attack for this one is the so-called kerous roasting attack. Easy and very effective, very powerful

attack. So when you look and compare legacy service accounts to any other managed service accounts standalone group or delegated what is the main benefit thinking that if the managed service account is more secure than the legacy service account that's not true has similar issues different but similar the really really difference between the legacy service account and any other managed service account is the automatic password management. The legacy service account has a static password. You have to change the password. With the managed service account, it's a system itself that's based on a certain interval. Most of the times it's 30 days. We'll talk about it more later on. Um it changes the password using a specific mechanism

and it keeps changing it and changing it and changing it and the password is very very strong. It's not crackable. So the kerous roasting attack against such an account managed service accounts is impossible because the passwords are too strong. So kerous roasting would be history for these accounts because like I said it's impossible to execute at least for the manus accounts. Let's I decided let's ask AI for kerbus roasting being history. This is the answer that I got a picture. Well, I asked, "Draw me a picture about showing me what does it mean Kurt's roasting being history." This is what I got. I'm like, well, this was not the intention that I had in my

mind. And I still don't want to draw the picture. I Okay, I changed the prompt. I just added an exclamation mark. What is the picture now? This. Well, the emotion is right. It's not what I was thinking of, but at least the attent the emotion of Christmas roasting being history is correct. So, compared to man the the legacy service accounts, the managed service accounts um have one benefit. It's the automatic password management and also service principle name management, the SPN on the accounts. But still, you still have to have a naming convention. You have to own it. You have to maintain it. And if you don't need it anymore, think about reertification. Get rid of it. Or if you do need it,

extend it. You need to have some kind of a process that from time to time reertifies those accounts to make sure that if it's not needed anymore, get rid of it. In my view is anything in your active directory or basically on in any other system. Anything is a risk. Anything you don't need it, get rid of it because every risk needs to be managed somehow. So and also the last one because of the whole mechanism of the password and all all the things work whether it's a legacy service account or a managed service account the server that account is being used on if that server is not protected correctly any account legacy or managed it's toast

compromise the server anything on it including all the accounts are also compromised so make sure comp to to secure the um server itself. Focusing on standalone manage service accounts, you can only use it on one computer. It's impossible to use it on multiple computers. So, first you link it to a computer in active directory. Then you have to install it on the server itself, test authentication to see if it works, and then configure the server, schedule task, whatever. Very easy. If you want to transfer it, just have to remove it from that server, unlink it, relink it, and then do all those steps again. Um, password management. As soon as you install the ser the the the standalone

service account on a server, the password will immediately be set on the account itself and also told to the computer what it is. So that the computer at some point in time starts managing it every 30 days, which is the default of the computer. The computer itself changes the password every 30 days. So does the standalone manage service account but does it doesn't mean that it's using in the interval is itself but it will not let's say change it at the same point in time. It's just the interval that is exactly the same. The behavior is also exactly the same. So if you look at these security options, if you configure these computer, these security options on the

computer for the computer itself, it will also uh influence the behavior of the so-called standalone manage service account on that computer. It follows the exact same behavior. when I was investigating all this the standalones the groups and delegated managed service accounts investigating finding information colorating it uh um with uh event logs it was really difficult so in the end I decided for every single account and this is for the standalone manage service accounts to write the script that outputs all the data that is relevant and important uh um and available in active directory to show it to me so that I can have all the information in one view so that I can use it and then when you look at it one

of the things that you can see the password last set of the standalone manage service account when it was last set also of the host itself and also um to which server it's being linked. So we have all that information and this is what this one is specifically for standalone manage service accounts. So group manage service accounts a different class totally different mechanism centralized password management. So where the passwords for of a standalone managed service account was managed by the computer itself with a group managed service account, it's not managed by the computer anymore because the group managed service account. It was one of the problems with the standalone one. You can only use it on one computer.

With the group managed service account, you can use it on multiple computers. And because of that, if you have 10 computers using one account, who is going to manage the password? All of them. That's going to be a mess. one still going to be a mess. So the only thing that can manage that password is active directory itself. And to make sure that when the calculation of the password occurs and the end result is always the same, you need to have a you need to have specific data. And one of the the the the specifics that are in importance is the so-called KDS root key that is in active directory and that every single active directory domain

controller can manage and access and also access and then using specific information of the account itself. It calculates the password. So the answer or the response for the password will always be the exact same. Every every single time you ask for the password, it will be the the the exact same value. So looking at the KDS root key, it has a key identifier because that's what is being used to reference to that key. It has a creation time when it was created and a so-called use start time. There's a difference between the two because when you create an object, it has been created at a specific moment in time. But can you actually start using it immediately? The answer is no

because it still has to replicate to all the other domain controllers in the forest. And if it's a huge forest, it can take quite some time. So you need to specify a moment of time that you can say this is when you can start using it. So it first needs to replicate and only after that you can use it. That's the what the start means and the start your start time means and it can be shared across multiple computers but I already already mentioned that which is the flexibility compared to standalone ones or you just focus on one computer so you can choose whatever you want. Great. The manage password interval and this is a tricky

one that you need to pay attention to. By default, no by default when you create a standalone sorry a group manager service account and you don't specify an interval which nobody does by the way you always get the 30 days interval. My suggestion is to never use the 30 days anymore to use a lower value of 3 to 5 days. There's a whole reason behind it, but I will throughout the the the presentation I will talk about it. But let me already give you a hint. Why would you need to decrease the value? Use a lower value. It's not necessarily that the 30 days are are are less secure. That's not the reason. There's one scenario that helps

you if the interval is lower. And the scenario is imagine the very painful procedure of performing a full password reset of every single account of your active directory. Looking at all the accounts that are possible within your AD there are two accounts for which is impossible to perform a password reset. One is the group managed service account the one you see on screen and the other one next one it's a delegated managed service account. It is impossible to perform a full password reset against those accounts if you need to because those follow a specific interval. For group managed service accounts and delegated managed service accounts, you would need to wait two resets. So when you think about two resets and also the

default 30 days, when is it let's say secure again, 60 days. That's quite a long time. you can't wait 60 days. So decreasing it to say let's say 3 to 5 days you have less time that you need to wait for. Obviously you need to have a look at your replication of your ID to see how that it behaves when you lower it. But not using the 30 days is definitely very recommended. Use something that is lower. The manage password um is the identifier that references the key identifier. So that the account knows which key KDS root is going to be used the first one the the the current one but also the previous one because group manager

service accounts and also delegated manager service accounts have a so-called current password and a previous password and that mechanism is important because when something changes it still needs to replicate and all the servers using those accounts can still use the previous or the current one so that it has the time to switch from one to the the manage password. If you think that both group manager service accounts and delegated service accounts do not have passwords on the account configured themselves, they do. Every single authenticatable account, users computers group delegated manage service accounts, all of them have a password on the account itself. But what is the manage password? The manage password ser uh sorry attribute

is a constructed attribute and constructed mean it's calculated on request when you actually need it the system is going to calculate what the end value is going to be and um so when a system uses a so-called group or delegated managed service accounts because the mechanism is the same for both um a system that is allowed to retrieve a password because it's allowed it's allowed to ask the domain controller Hey, give me the password the domain controller using the KDS root key referenced in the through the identifiers but also specific information of the uh account itself including the interval because one of the things that I didn't mention before the interval can only be specified

during creation afterwards you cannot change it anymore so if you were thinking oh let's change the existing ones to 30 that's impossible you would need to recreate all the accounts that's the only way to do it so based on the metadata of the account itself itself it recalculates the password hands it over to the server so that the server then can use the account and authenticate it against active directory that's how the whole mechanism works as I mentioned forcing a password reset is impossible there is a trick though with all kinds of steps it's basically fooling the system and it has has quite a lot of work in it but forcing like any other account it's not possible anymore

you can query the password from your active directory. If you are not allowed to query, you need to be in a specific list which is let's call it a so-called permission on that account. If you're not allowed, you will not get an answer from the domain controllers. If you are allowed to retrieve the password because otherwise it would be very easy and everyone would be able to request a password. If you are allowed, you get the password by just performing an LDEP query. And then if you have a mix of writable domain controllers and also god forbid read only domain controllers um only the writables can calculate the password the roodc's are not able to

calculate the password and the reason for that it's inactive directory itself because when you look at it this is the let's say the secret information the the stuff in the red box the secret information of the KDS root key itself it is available on the writables but it's not available on the read only domain controllers and the reason for that is because those attributes are part of the so-called filtered attribute set. Why? Because if it's a secret by default read only domain controllers are untrusted. Those were designed to be an untrusted location. So anything that is secret by default does not go to RODC's. So that's why those cannot calculated. And I was talking about how the manage

password is being calculated but also who is allowed or not. There's an attribute on every single account for a group manage service account but also delegated that is the so-called MSDS group MSA membership which is basically a permission. If you are if you have an account or a group that is part of that alle that membership then you are allowed to request a password. It needs to be specifically defined. By default, it's empty. So, you need to put something in there that is allowed. Most of the times, it is a server or multiple servers, but because this attribute is quite difficult to manage because it's a permission and there's no really easy interface for it

except for, let's say, using PowerShell, most of the times people put a group in there and then add computer accounts to that group.

So again one of the examples regarding the password how it works. So using 80 powershell I'm assuming in this scenario the first box that you are allowed to retrieve the password and because you are allowed to retrieve the password you will see this attribute the third from the top MSDS manage password. So if you are allowed, you will actually see a value. If you're not allowed, even though if you request it, nothing is returned. So in this case, you will see all kinds of crazy stuff. And then using DS internals, you can change or at least uh recalculate that so-called Chinese stuff that you see on the screen to something that is a hash, the current one and the

previous one. Now if you again use DS internals and um check what the password is on the account itself. So the top one was requesting ID the domain controllers and then in the lower right cornering you see what is on the actual account and as you can see that it's exactly the same because otherwise the whole authentication would never work. Again for this type of account group manage service accounts I created again a script that displays all the information. Feel free for all those scripts by the way uh with the QR codes or the links um to grab them from my GitHub and uh use them as you see fit. Again, when it was changed and when you

look at a few columns, PBW int is the so-called interval. You see 142 at the top, but also the default 30. And then you see a column PHC, which is password should have changed. And then you see yes or no. And you see all dox and dx is abbreviation that I came up with days until expiry. Both columns tell you the exact same information. If you look at the answer no or yes should have changed. If the answer is if you see that it's yes then you know that the account is not even being used by a server or that something is broken. If you it's not easy visible but you see somewhere in the middle minus 76. Well I

know from the top of math that was minus 760 something days that means that the password of that account should have already be changed almost two years ago and this is the output if you have the accounts that are in your active directory but nothing is using them. In other words that could be a risk looking at the permissions that those accounts might have. So make sure to look at your active directory. You can use these scripts if you want to and if check if you have unused accounts which current um KDS root keys are being used also when they were created um um and also the previous ones which are the principles that are allowed to get the

password. On the left part you will see what is configured but also on the right part of that box you'll see which servers actually are allowed. It basically expands the whole membership so that you can see which um can receive based on the same account name or the sit delegated manager service accounts. New cool stuff in 2025. It's basically the exact same stuff as a group managed service account with a huge amount of steroids on top of it. It has more capabilities because Microsoft saw that people were not moving away for the legacy stuff. So they had to come up with something that helped those people. this helps them. There are just unfortunately a few catches like

the group managed service account active directory has a copy and the server that uses the account also have a has a copy of that password. The difference between delegated with with delegated service account is AD obviously has a copy of the password but the survey itself does not anymore because it works differently totally different mechanism. Why is that important? Well, there are reasons that I'm not going to to discuss right now because quite a long story there's a whole scenario on top of it. It cannot be requested anymore free via LDAP where the group manager service account could be queried. The delegated one cannot be queried anymore. It has to be requested through a so-called ticket

granting service ticket through TGT again for the account that is allowed to request it. And this is the reason when you look at it for a GMSA, everyone is allowed to request the password. And when you look at the DMSA at the bottom, you see at the left a deny. In other words, they prevent an LDEP query for delegated managed service accounts. authenticated users are allowed to see GMSAs but not the MSAs and again it's a permission they they they they sec they added more security so that is not easily visible by let's say regular accounts so they again they changed the permissions in this case they removed a specific permission being authenticated users read so because it was removed cannot be

used then again the MSA support you have to think about two things. First you need to have a active directory that actually supports the account supporting not just the creation itself because to create delegated manage service accounts you only need to extend the schema that's it to actually use those accounts you need a 20 at least one 2025 domain controller at least one but the advice is have more there's a reason for it um if you don't and and and you also need to have and this is the downside of this account so Microsoft oft helps or at least try to help people to move from those delegated legacy sorry from those legacy accounts to the delegated ones

but then the conditions of when can you use it are crazy think about it as I mentioned you need a 2025 domain controller and you can only use a delegated managed service account on a 2025 server so if you think oh let's upgrade active directory to 2025 and start using delegated manage service accounts no you have to move all your application landscape to 2025. And then when you think about it, nobody's going to do that in a very short term. It can take years. So support is not available, at least not enabled by default. If you have 2025, 2025 server, it's still not enabled by default on the server itself. In AD, everything is ready to go, but

it's on the server itself. And there's a reason. If it's not enabled, as soon as you try to use a delegated man service account, you get something like password or incorrect doesn't work because the whole thing, the whole mechanism is disabled. Can be enabled through GPO or registry. And the downside and here it comes although the documentation tells you and it's in the box that this one that appears. The documentation tells you you only need one domain controller. Technically that is correct. But if you are if you have quite a lot of servers and you only have one 2025 domain controller and let's say lots of 2025 servers using delegated managed service account. All those servers will not look at any

other domain controller anymore besides the 2025 one. So let's say that if you have 2019 or 2022 and just one 2025 as soon as you enable delegated manage service account support on that specific server authentication for any account doesn't matter what user computer the group manage service anything will go to the 2025. So probably that thing will burn down because of the load and all the others are doing nothing. So that's why technically only you need one but realistically you need a lot more to be able to support the whole load. There are two use cases for DMSS. the native use like the GMSA, you have a service schedule task and you configure the account directly in there

or you have a legacy service account, the one with the static password and you link it, you migrate it to a delegated one so that it basically takes over. The account still needs to exist, the old one, but it the whole DMSA thing takes it over and that allows you to migrate it. And the last one is the exact scenario that Microsoft is focusing on to help people move away from that legacy stuff. You're not really moving away because you need still you need to keep him in place in a specific state. We'll discuss that later. One of again tricky parts at least it could be tricky is the DMSA creation and management is considered tier zero in in

other words very high privileged because of the powers that it has. the inner guts DMSAs it has a so-called state the DMSA account and the superseded account the superseded account see as the legacy account whatever that may be the intention of the so-called superseded account is a service account but there's nothing technically that prevent you from using something else like for example instead of using a service account let's spe link let's for example link the domain admin to the DMSA. What could go wrong? Own the DMSA. If it's linked with the domain admin account, you own the domain and maybe even the whole forest. It depends on all kinds of things. It's like an ID.

Everything it depends. So, it has a state. When you look at the state of these accounts, zero, at least for the DMSA, it's not being used. Migration for one, the migration has started. there's a reason for it and it has ended if it's two and has three native views like a GMSA the superseded account has the same state it needs to matched with the other one especially the migration and the end state need to be the same and then those accounts are linked with each other the legacy account points to DMSA the DMSA account points to the legacy service account and that's how both know about each other there's a problem though admin has holder has a process that protects

powerful accounts like for example the domain admin account. So all accounts in active directory have specific permissions you as a person can configure specific permission on groups of accounts or whatever you want. But when you have to deal with so-called protected groups and protected accounts, those permissions are inherited by from not by but from admin SD holder. It's a process that checks it and stamps those the permissions that are on as me holder. It copies them onto those objects which protects them so that not so that regular users cannot let's say misuse them. However, if you link a protected account, doesn't matter which one, to a DMSA, you would expect that the DMSA also becomes a protected

account. No, it does not. So, suddenly through the DMSA, you would be able to which is not for example protected because it's linked. You can suddenly access a protected account. Something to keep in mind. And again for the DMSA, same story. as the um um group manager service accounts with the exception date that over here you can see the state and also which account is being linked with the DMSA in the upper left two red boxes initiating the migration. The whole idea of initiating the migration is as I mentioned tier zero high privilege. So only domain admins can initiate the migration from a legacy service account to a DMSA. Cool. It's privileged and secure. When

that happens, you need to start a commandlet. That commandlet under the hood triggers a so-called operational attribute. and it triggers an an operational attribute because the meaning of an operational attribute is not just writing one action or one value. know the operational attribute is basically telling the domain controller and then somewhere in the code it's specified what it needs to do but the operational attribute is always about performing all kinds of actions multiple actions and to not put that burden on you that's how they did it you trigger the operational attribute through a through a a PowerShell command lit and then the domain controller performs all the actions that are needed for all the things to network.

What happens? The legacy service account gets write permissions on the allow to retrieve password list, the MSA, the group MSA membership attribute. So the legacy service account gets right permissions onto that attribute. And there's a reason for that that I will explain later. And there it is. When you start the migration, the DMSA receives state one and it links the service account to the DMSA. And the red text is just basically to tell you that hey that group is not part of that whole process. It was something that I already had put there just to see what happens with it. So it's not part of the whole process. When you look at the legacy service account itself, the

same is true. It links the DMSA and it puts the exact same state which is one and one in this case means the migration of this whole thing has started before the migration. This is how authentication works. You have a service using the service for in this case SQL. You've got a server running SQL at SQL service runs the the the service account.SQL. It authenticates to the domain controller using its TGT and it requests a TGS. Done. Nothing special. Now, during the migration, there's a difference. The reason that it's not a zero or one, no, it's start the migration, wait some time, and then complete it because it's all about those servers that are allowed

to use that account need to have the time to tell the new account that they are going to use it by allowing it to grab the password because it's a whole different mechanism and it needs to be it needs to be able to complete the whole process. So there's a there's why there's a time between the start and ending it. So how does it work? The service account requests a T uh with its TGT requests a TGS. um the domain controller responds with that TGS but in this case the TGS has it uh the the well it it is a TGS but in the end it's basically a TGT in a TGS but the domain controller responds with

a additional information >> that >> in this case the domain controller responds hey you have been because the migration is now starting meaning one the domain controller now tells the machine hey although you are using this legacy service account in the future and that's what you see on the right corner. This is what it's that is been superseded by a new account and in the right corner you will see hey this is the legacy sorry this is the delegated managed service account that it's going to use be used in the future. So it's already preparing the server telling it this is what's going to happen in the future and because of that in the third action

because the server was told this is the new delegated managed service account that's going to be added be used in the future the server now uses this legacy service account to add the computer account of the server itself to the there's a whole sorry to the allowed to retrieve password list on the delegated managed service account. So let's retry again because it's a very long story. The server was told or the server knows I'm going to use the legacy service account but the domain controller told it no no no well it's true for now but in the future this is what's going to happen. So because the server was told what's going to happen in the future, it needs to prepare

itself. Because of that, the server got that that answer, the server will now use the legacy service account to add itself and itself in this case the computer to the so-called allowed to retrieve password list on the delegated manage service account. Because when an account is in the allowed to retrieve password list, it is allowed to request active directory. Hey, what is the password? And there it is. When you look under the hood, you will see that on the delegated managed service account, it updates its attribute by adding the computer account completing it. That's when all the servers involved in this whole mechanism because most of the times and that's why I'm using SQL. SQL is a cluster of

servers. at least two or maybe even more. So all those machines have to go through the exact same process. And when you look um at the whole thing, you need time so that all those servers have had the time to process all the information and everything is ready to say let's complete this. And when do you complete the uh the migration? It's you that determines this. It's not the service. No, it's you that determines okay, we've had enough time. Let's complete the migration. And again you complete the migration by using and this is by the way per DMSA account. It's not a whole thing. No it's per DMSA account. You complete the migration using PowerShell

commandlet which then again triggers a operational attribute but in this case with the value two meaning the state is going to move to two which means end of migration. And this is what happens. It removes the permissions that were set before. It removes the permissions of the delegated sorry of the legacy service account from the DMSA because it's not needed anymore. In addition, it also performs and this is what I what I meant. The servers have added themselves to the principles allowed to retrieve the manage password list. This is what happened during the migration. And then at the same time the accounts are linked. The legacy service account and as you can see on the lower part is disabled.

It's going to be disabled. When that also happens, the state is obviously changed to two and the configuration that was on the legacy service account is going to be migrated to the to the delegated managed service account. Think about SPNS. The only thing that is not migrated that's key is kept on the legacy service account is are the group memberships. Those remain on the legacy service account. Those are not migrated. And that's you might think but why is that why is that not migrated? Well, I will tell you how the whole mechanism works and then you also probably will understand why it could be an attack. So on the right you will see in the

black box all the things that are migrated from the legacy service account to the delegated one. One thing that still needs your attention is the so-called allowed or denied list on RODC's. If it's specified through a group then everything is fine because then it inherits the group membership. But if an account is specified directly on that list you have to migrate that information itself because those are based on distinguished names and those are not transferable in this case. How does it work? You can see that the account is running for the SQL servers and as you can see it is linked with the DMSA but it's disabled. The arrow pointing down and still authentication still works although the account is

disabled. You are asking why I will explain. The server will now again try to authenticate using the leg the legacy service account although it's disabled. Let's say that the server doesn't know it's disabled because it's like hey this is what it's running on. Let's use it. The domain controller responds back and that's what the ticket means. Client revoked. In other words, the account is disabled. Dude, you cannot use this. Okay. But again, almost similar to the previous step, the old account has been disabled. Dear server, the old account has been disabled. Don't use that anymore. Use this account, the delegated managed service account that has been linked with the legacy one which is in the right corner, the DMSA one. And

because the server was allowed to retrieve the password, it now knows okay, I will try to use that one. So it issues and a reauthentication for using its own server account in requesting a TGS from the active directory saying hey give me TGS for this DMSA. Think about the configuration being moved the group membership still being on the old account. What happens then? And this is the fun part. Active directory because those accounts are linked migration has completed. It looks at the pack all the configuration of the legacy account and the configuration of the delegated me managed service account and it merges all together and that's why you can see that uh in the in the left part that the

groups are merged into one pack. In other words, anyone using that DMSA has the powers of the DMSA itself but also of the legacy one. Think about it. what could go wrong but also this is also another one the account as soon as the migration has completed should and I'm talking about the legacy one as soon as the migration has completed do not delete the account deleting deleting the account breaks the linkage between the service and the DMSA so the whole servers will basically drop that it's disabled. Keep it there. Do not delete. If you have the question, can I change the password on the legacy service account? Yes, you can. But don't do it right after completing the

migration because the migration allows you to go back. And if you go back and you've changed the password, stuff will break. So, as soon as the migration has completed, wait, be patient. Let's say after a month or so where you have confirmed everything is working then change the password of the legacy one can be anything change it to I don't know put something in there you don't even need to know what the password is just put something in there as long as it's very strong because when the packs are merged the system will grab the hash every single time the TGS is generated it will grab the current hash of the legacy service account and put it in the TGS

think about it again what could go So you have a TGS, you have a DMSA that is so powerful in terms of permissions. When you perform such a migration, I think for many it will work, but there's a few and I only know about one of them. It's ADFS. If you perform such a migration using a legacy service account and you're still using ADFS and you complete the migration, ADFS will break. You had all kinds of nice errors complaining all over the place. And the reason for it is that ADFS internally references the old account. So you have migrated on the server, you have migrated in active directory, everything is done. But ADFS itself, it uses a

database. It references the old account. But that was not changed by you. So that's why ADFS will break and complain all over the place using these events. What can you do? It's fixable. you just need to perform an additional action because when you look in the database you see what the previous value is which was um marked in red the existing service account you add during the migration the new service account which is the DMSA so it becomes aware of the new one and then when completing it you remove the old one then all is fine the moral of the story is when you perform such a migration make sure to investigate your application if to

understand if that application has some let's call it hard-coded reference to the account being used. If it has, you need to do something and you need to figure out if it's possible to let's say tell it to use it the other account because if it's not then probably you cannot perform the migration bad successor I basically I think gave all kinds of hints and this is what without the patch before August 12 2025 merging the pack what are the conditions so merging the pack the memberships but also the hashes of the old account there was just one condition. Two conditions. It looked at the end state and also which account was linked. It never looks at how it got to the

account state. How it got to the account state means unused zero. You start a migration, it's one and you end it's two. A whole flow of things. But nothing prevents me from just writing to as a state link it to some account known account. What are known accounts? No. Which accounts in active directory have known distinguished names and are very powerful? There are two. Who knows? >> Sorry. >> Domain admin. >> Yeah, there's one. The other one step >> no >> enterprise. >> No, it's the same domain admin. Enterprise admin. It's the default domain admin. That's the first one, but there's another one. The curb tgt account. So, but if you link the the the domain

admin to a DMSA that you control without this patch, you own the forest. Period. Because it's just and the account can even be disabled. Just link it at status two on the DMSA. Done. Game over. Curb GDT account is also a known account. Golden ticket attack. That's basically what you could do. So, one is taking over the forest and the other one is the golden ticket attack and then leads to the taking over the forest. So well-known accounts very tricky and as I mentioned I can write and for whatever reason Microsoft in this case did not protect the regular LDEP rights to those attributes I still do not know why because they should have protected

it. So anyone controlling any DMSA again without the patch anyone controlling the DMSA through the create child permissions or full control right decel or whatever. So if you control the DMSA in any way in any form you are able to link it to any account and take over the whole thing. it will hurt. And then this is what I've done by using a bad actor account requesting ADMSA to which I linked the default domain admin just to try it out to see what happens. And this is what you will see. Look on the right all the RITs meaning I inherited all the powers and permissions of the domain admin. So now I have a DMSA that's a nothing but

because it was linked to the domain admin I now have all the power that I have domain admin enterprise admin the domain admin account itself so I could have a lot of fun in this ad it's basically game over patched successor that is with the patch they changed a few things so at the beginning it only looked at the state and the link on the DMSA itself. So if you control the DMSA without the patch, you're done. Now they changed and added conditions. If you control the DMSA, won't work anymore with the patch. You also need to control the account that you are linking to. And that is not possible unless you already have other

permissions. But then okay, because now Active Directory looks at the state for both accounts and they need to be linked to each other. So it has become more difficult still not protected but then additional control is needed because think about it a domain admin kersgt account those are protected accounts admin holder protects them with special permissions nobody can just do stuff on those but imagine having an account that has so many powers because of permissions in ID but it's not protected By linking that account, if I still can control it in some way or another, by linking that account, I can take over whatever that account can do. And if it's like something like having full

control on, let's say, admin SD holder or resetting passwords, I can still get around again all those permissions, but now it's on the account and the DMSA itself. The same permission set still apply. And when you look at it, although it has been now controlled or more contained, the whole attack technique is still valid. It's just more difficult to get there. Not impossible, more difficult. If with the patch you tried the old behavior, you get a kerbus error. Basically, ah, it doesn't work because of the patch. They changed it. Tier zero. How do you, let's say, monitor this? As I explained at the beginning, there's a whole flow 012. If suddenly somebody writes two and

links an account that's not right. So you need to monitor for that. If suddenly there's there is no flow but stuff is written for patch successes. Same story. If suddenly on both accounts somebody registered this the same state and the linked accounts something is going wrong. But because both still need to go through the whole flow. So one of the things key things that you need to do is review your delegation model. I wrote a script in active directory that checks for all that stuff. So these are the the the things you need to look out for because account um operators has permissions all over the place. It's very powerful. And also look at the permissions and then using

the script that I wrote, it outputs you where the explicit permissions are or or configurations that you need to pay attention to. So it's on my GitHub by using the QR code or the link. Consider implementing a tearing model hiding objects. If you hide the object, you cannot determine its DN. Now both the KPGT account and the default domain admin are in the users container, default container. So if you create a taring model that has let's say been enhanced with very special permissions, you also need to make sure it's invisible from a content perspective so that regular users cannot see the content of that touring model. If you put those accounts in there, you cannot determine the DN anymore.

But then again, even with the patch, it's just to make sure that everything is is as secure as possible. moving the default domain administrator account. Um, from a Microsoft perspective, Microsoft tells you, yeah, it's okay if you do that. For the cryptog account, they tell you it's not recommended, whatever that means. I don't know

during my investigation and I was not the only one because many others also performed the exact uh investigation and uh published this um is one of the things that that I found on let's say that you do not want to use DMSAs at all. There's one thing that you can change in the schema by the way it's reversible. it's explained in the in the link that I'm going to show you is um to prevent writing anything to specific attributes important for the whole DMSA part and because you block it nothing can be written it means that the whole DMSA migration scenario cannot be used you can use it for native use but you cannot use it anymore for the migration start

where which basically means that this whole attack technique doesn't work anymore it's something that I found out it's explained it's can be configured. It's in the schema. Some may think uh oh schema you cannot reverse it anymore. Normally that's true but in this case you can still reverse it. So it's explained um in these blog posts all kinds of blog posts talking about how this whole thing works and what you need to pay attention to. I talked a lot also about the KDS root key because the KDS root key is the source for the password of the group manager service account and the delegated managed service account. Anyone owning the KDS root key can generate any

password, the future one, current one and even sorry the the the past ones, the current one and even the future passwords because if you own the source key for the passwords including the metadata of the account itself, you can generate whatever it is and you need to audit it. So in every single domain you need to configure the cycle um you need to configure auditing on all the domains and then configure the the the the the auditing on a specific keys so that if anyone ever thinks in touching those keys you were warned about it because nothing really nothing should ever access those keys besides the domain controllers themselves. No person needs access to those and this is how you can configure

it. So if a bad actor in this case touches the keys, you will see an event ID and that's what you need to look out for. But be aware that the domain controller also touches those keys. So those you can this is a false positive. The other one is a true positive. Something just to be make you aware of if you're using managed service accounts standalone group or delegated by default it's put in the managed service accounts container. And I've already talked to companies that mistakenly they deleted the managed service accounts container and all the managed service accounts in them. Why? Many OUS and containers are protected from accidental deletion. This one by default is not.

So by just adding one checkbox, you can prevent yourself making a mistake which is oh which is the check box here on the left protect from accidental deletion. Just check that and it's preventing you from making that silly mistake. Um, caching the account using the guey for the managed service accounts. It's not possible caching accounts on RODCs. You cannot use the GUI because as you can see it's computer and users only. You can use PowerShell though. And then when you see that the dates on both the writable and the RODC are exactly the same including the version as you see on the right then you see it has been cached. If you want to remove

it again well the password has already been exposed on the ROC. The best way would be to remove it from the allowed list then reset the password. But then again how do you reset a password on a GMSA you can't? You have to wait. less impactful but also less secure is to purge the password from the RODC. And then as you can see the writable tells you what the exact the actual date is with version 4 and the ROC tells you version 4 with some data in6001 which means it's not cached.