what is reset account?
in [Active Directory]
|
Prev: repadmin issues
Next: LDAP win2003/SSL
From: Joe Richards [MVP] on 6 Jul 2006 10:15 As for the relative insecurity, it entirely depends on the purpose of adding the computer to the group and what access(es) it grants. The issue comes in when you grant something that you want the computer to be able to see but not the users and the users have physical access or any type of access rights that allow launching a process in localsystem or networkservice (or localservice if securing something local). Because at that point, the person can gain access to a process running in one of those contexts and will be running as the computer so will be able to see the information that was supposed to be locked off. In general this applies to users who are admins or power users but if someone ever got access to control the settings for a service or the ability to modify the info for a service then it is possible to escalate to the proper security context. Also obviously, anyone with physical access can do it if they want. Securing things like GPOs has limited use when doing this. Overall, I am not a huge fan of group filtering, I have seen it go pretty bad on 3 different occasions. One of those occasions happened to me when I applied the GPO team's updates to the production domain and the ACL got wiped in the process (the poorly written script blew out midstream) thereby clearing the Group requirement which protected the GPO and thousands of workstations and servers around the world locked down to kiosk mode. But anyway, say you set up a computer policy that all it does is set the password on the admin account. You feel it is safe because you locked it down so only the computers have access. There are two attack vectors: The first is to impersonate a computer, that is easily accomplished if power user or admin or you have physical access. The second is to set up a network sniffer and just pull the batch file off the wire or the GPO off the wire as it gets brought down to the PC. I used that once as a stepping stone when doing a security check for a company several years ago and within an hour had escalated myself all the way up to EA and sent an email from the Chief of Security's mail account. The email recommended that the consultant brought in to do a security check was amazing and should get double his stated rate because he was so helpful. :) I thought about walking through what I did to compromise them but I think it would do more harm than good. It generally isn't good to explain in detail how someone can walk in off the street and compromise a corporate network. Security is just far too lax in most companies, even those that think or partially try to be secure including some very large major companies. Most folks will often think they are secure because they think, no one would ever do that, the consequences are too great if they get caught (say like tailing someone through a secured outside door to a building) but honestly, not everyone has the same value systems when looking at doing things and there are people who would not even think twice about stuff that most people would be far too scared to do because they think, someone MUST be watching. The scary fact is, someone usually isn't watching or is watching so poorly it is worthless. Secured doors are worthless unless they physically only allow one person to pass at a time or there is a security guard standing right there, anything else is insecure and can be breached. Once inside... how well does your network stand up? What rights do people have by default on workstations? In 90%+ of the companies... Admin. That can be used right there to cause a heap of trouble for most places. The larger the company, the more likely someone could walk into the building and get to a logged in working PC with very little to no issue or chance of being caught. joe -- Joe Richards Microsoft MVP Windows Server Directory Services Author of O'Reilly Active Directory Third Edition www.joeware.net ---O'Reilly Active Directory Third Edition now available--- http://www.joeware.net/win/ad3e.htm Herb Martin wrote: > Joe Richards [MVP] wrote: >> Well it avoids the rejoin ASSUMING that the user who is doing the >> reset can force the client to do a password change. If the client >> isn't talking or the person involved has insufficient access at the >> client or the client is offline (which I guess is the same as not >> talking) the reset will only update the following attributes in AD (a >> password change) >> >> dBCSPwd >> unicodePwd >> ntPwdHistory >> pwdLastSet >> supplementalCredentials >> lmPwdHistory >> >> and it will be up to some other process to sync the workstation with >> the account once the workstation can talk again (or the proper >> credentials are involved that will work with the current state of the >> client machine). > > As usual, Joe, you teach me a quite a bit. Thanks (again and again). > > [Also, I BELIEVE that I have seen one case where resetting the > computer account, along with repairing all other DNS problems etc, > STILL required a Win2000+ computer to be unjoined and rejoined to > the domain even though we TRIED our best to avoid that method.] > >> As Herb indicated, it was never necessary to delete and recreate. It >> wasn't critically important and usually still isn't if someone does >> though. While folks can add computers to groups, the relative >> insecurity of that still makes it something that isn't generally advised. > > I would appreciate hearing more about this insecurity because there > are certainly cases where adding computers to groups is the > only practical choice, e.g., > > Assigning software to computers where the shares > and NTFS files are restricted so that only > certain subsets (i.e., Groups) of computers > can download that software > > GP filtering when no better way is available to restrict > a GPO to a particular subset (group) of computers. > > >> It is actually possible in an NT4 environment to add computer accounts >> to groups and ACLs, but I believe the native tools would choke if they >> tried but could display that just fine. Its use was limited though as >> Herb mentioned, kerberos didn't exist as a domain auth mechanism to >> allow the security relationship to be built up for standard Windows >> security functions across th
From: Herb Martin on 14 Jul 2006 00:41 "Joe Richards [MVP]" <humorexpress(a)hotmail.com> wrote in message news:%23SoNTaQoGHA.4728(a)TK2MSFTNGP05.phx.gbl... > As for the relative insecurity, it entirely depends on the purpose of > adding the computer to the group and what access(es) it grants. The issue > comes in when you grant something that you want the computer to be able to > see but not the users and the users have physical access or any Ok, it doesn't really affect the cases where I would typical want to use or recommend it. Read access to shares that offer software intended to be deployed based on computer account. Such doesn't require perfect security, just practical control. -- Herb Martin, MCSE, MVP Accelerated MCSE http://www.LearnQuick.Com [phone number on web site] "Joe Richards [MVP]" <humorexpress(a)hotmail.com> wrote in message news:%23SoNTaQoGHA.4728(a)TK2MSFTNGP05.phx.gbl... > As for the relative insecurity, it entirely depends on the purpose of > adding the computer to the group and what access(es) it grants. The issue > comes in when you grant something that you want the computer to be able to > see but not the users and the users have physical access or any type of > access rights that allow launching a process in localsystem or > networkservice (or localservice if securing something local). Because at > that point, the person can gain access to a process running in one of > those contexts and will be running as the computer so will be able to see > the information that was supposed to be locked off. In general this > applies to users who are admins or power users but if someone ever got > access to control the settings for a service or the ability to modify the > info for a service then it is possible to escalate to the proper security > context. Also obviously, anyone with physical access can do it if they > want. > > Securing things like GPOs has limited use when doing this. Overall, I am > not a huge fan of group filtering, I have seen it go pretty bad on 3 > different occasions. One of those occasions happened to me when I applied > the GPO team's updates to the production domain and the ACL got wiped in > the process (the poorly written script blew out midstream) thereby > clearing the Group requirement which protected the GPO and thousands of > workstations and servers around the world locked down to kiosk mode. > > But anyway, say you set up a computer policy that all it does is set the > password on the admin account. You feel it is safe because you locked it > down so only the computers have access. There are two attack vectors: The > first is to impersonate a computer, that is easily accomplished if power > user or admin or you have physical access. The second is to set up a > network sniffer and just pull the batch file off the wire or the GPO off > the wire as it gets brought down to the PC. I used that once as a stepping > stone when doing a security check for a company several years ago and > within an hour had escalated myself all the way up to EA and sent an email > from the Chief of Security's mail account. The email recommended that the > consultant brought in to do a security check was amazing and should get > double his stated rate because he was so helpful. :) > > I thought about walking through what I did to compromise them but I think > it would do more harm than good. It generally isn't good to explain in > detail how someone can walk in off the street and compromise a corporate > network. Security is just far too lax in most companies, even those that > think or partially try to be secure including some very large major > companies. Most folks will often think they are secure because they think, > no one would ever do that, the consequences are too great if they get > caught (say like tailing someone through a secured outside door to a > building) but honestly, not everyone has the same value systems when > looking at doing things and there are people who would not even think > twice about stuff that most people would be far too scared to do because > they think, someone MUST be watching. The scary fact is, someone usually > isn't watching or is watching so poorly it is worthless. Secured doors are > worthless unless they physically only allow one person to pass at a time > or there is a security guard standing right there, anything else is > insecure and can be breached. Once inside... how well does your network > stand up? What rights do people have by default on workstations? In 90%+ > of the companies... Admin. That can be used right there to cause a heap of > trouble for most places. The larger the company, the more likely someone > could walk into the building and get to a logged in working PC with very > little to no issue or chance of being caught. > > joe > > -- > Joe Richards Microsoft MVP Windows Server Directory Services > Author of O'Reilly Active Directory Third Edition > www.joeware.net > > > ---O'Reilly Active Directory Third Edition now available--- > > http://www.joeware.net/win/ad3e.htm > > > > Herb Martin wrote: >> Joe Richards [MVP] wrote: >>> Well it avoids the rejoin ASSUMING that the user who is doing the reset >>> can force the client to do a password change. If the client isn't >>> talking or the person involved has insufficient access at the client or >>> the client is offline (which I guess is the same as not talking) the >>> reset will only update the following attributes in AD (a password >>> change) >>> >>> dBCSPwd >>> unicodePwd >>> ntPwdHistory >>> pwdLastSet >>> supplementalCredentials >>> lmPwdHistory >>> >>> and it will be up to some other process to sync the workstation with the >>> account once the workstation can talk again (or the proper credentials >>> are involved that will work with the current state of the client >>> machine). >> >> As usual, Joe, you teach me a quite a bit. Thanks (again and again). >> >> [Also, I BELIEVE that I have seen one case where resetting the >> computer account, along with repairing all other DNS problems etc, >> STILL required a Win2000+ computer to be unjoined and rejoined to >> the domain even though we TRIED our best to avoid that method.] >> >>> As Herb indicated, it was never necessary to delete and recreate. It >>> wasn't critically important and usually still isn't if someone does >>> though. Whil
From: Sasi on 25 Jul 2006 07:12 Thank both of you guys for your explanations. some questions: 1.you know that you can rejoin a machine to the domain WITHOUT resetting its account(provided that you have the permission to write some property on computer object);so whats the point in reseting its account?isn't it useless? 2.about that refresh interval(30 days for win2k+ and 7 days for win2k-),how can I change this default intervals?is it through a policy or AD should be modified (ADSI edit and so on)? "Herb Martin" wrote: > "Joe Richards [MVP]" <humorexpress(a)hotmail.com> wrote in message > news:%23SoNTaQoGHA.4728(a)TK2MSFTNGP05.phx.gbl... > > As for the relative insecurity, it entirely depends on the purpose of > > adding the computer to the group and what access(es) it grants. The issue > > comes in when you grant something that you want the computer to be able to > > see but not the users and the users have physical access or any > > Ok, it doesn't really affect the cases where I would typical > want to use or recommend it. > > Read access to shares that offer software intended to be > deployed based on computer account. > > Such doesn't require perfect security, just practical control. > > -- > Herb Martin, MCSE, MVP > Accelerated MCSE > http://www.LearnQuick.Com > [phone number on web site] > > "Joe Richards [MVP]" <humorexpress(a)hotmail.com> wrote in message > news:%23SoNTaQoGHA.4728(a)TK2MSFTNGP05.phx.gbl... > > As for the relative insecurity, it entirely depends on the purpose of > > adding the computer to the group and what access(es) it grants. The issue > > comes in when you grant something that you want the computer to be able to > > see but not the users and the users have physical access or any type of > > access rights that allow launching a process in localsystem or > > networkservice (or localservice if securing something local). Because at > > that point, the person can gain access to a process running in one of > > those contexts and will be running as the computer so will be able to see > > the information that was supposed to be locked off. In general this > > applies to users who are admins or power users but if someone ever got > > access to control the settings for a service or the ability to modify the > > info for a service then it is possible to escalate to the proper security > > context. Also obviously, anyone with physical access can do it if they > > want. > > > > Securing things like GPOs has limited use when doing this. Overall, I am > > not a huge fan of group filtering, I have seen it go pretty bad on 3 > > different occasions. One of those occasions happened to me when I applied > > the GPO team's updates to the production domain and the ACL got wiped in > > the process (the poorly written script blew out midstream) thereby > > clearing the Group requirement which protected the GPO and thousands of > > workstations and servers around the world locked down to kiosk mode. > > > > But anyway, say you set up a computer policy that all it does is set the > > password on the admin account. You feel it is safe because you locked it > > down so only the computers have access. There are two attack vectors: The > > first is to impersonate a computer, that is easily accomplished if power > > user or admin or you have physical access. The second is to set up a > > network sniffer and just pull the batch file off the wire or the GPO off > > the wire as it gets brought down to the PC. I used that once as a stepping > > stone when doing a security check for a company several years ago and > > within an hour had escalated myself all the way up to EA and sent an email > > from the Chief of Security's mail account. The email recommended that the > > consultant brought in to do a security check was amazing and should get > > double his stated rate because he was so helpful. :) > > > > I thought about walking through what I did to compromise them but I think > > it would do more harm than good. It generally isn't good to explain in > > detail how someone can walk in off the street and compromise a corporate > > network. Security is just far too lax in most companies, even those that > > think or partially try to be secure including some very large major > > companies. Most folks will often think they are secure because they think, > > no one would ever do that, the consequences are too great if they get > > caught (say like tailing someone through a secured outside door to a > > building) but honestly, not everyone has the same value systems when > > looking at doing things and there are people who would not even think > > twice about stuff that most people would be far too scared to do because > > they think, someone MUST be watching. The scary fact is, someone usually > > isn't watching or is watching so poorly it is worthless. Secured doors are > > worthless unless they physically only allow one person to pass at a time > > or there is a security guard standing right there, anything else is > > insecure and can be breached. Once inside... how well does your network > > stand up? What rights do people have by default on workstations? In 90%+ > > of the companies... Admin. That can be used right there to cause a heap of > > trouble for most places. The larger the company, the more likely someone > > could walk into the building and get to a logged in working PC with very > > little to no issue or chance of being caught. > > > > joe > > > > -- > > Joe Richards Microsoft MVP Windows Server Directory Services > > Author of O'Reilly Active Directory Third Edition > > www.joeware.net > > > > > > ---O'Reilly Active Directory Third Edition now available--- > > > > http://www.joeware.net/win/ad3e.htm > > > > > > > > Herb Martin wrote: > >> Joe Richards [MVP] wrote: > >>> Well it avoids the rejoin ASSUMING that the user who is doing the reset > >>> can force the client to do a password change. If the client isn't > >>> talking or the person involved has insufficient access at the client or > >>> the client is offline (which I guess is the same as not talking) the > >>> reset will only update the following attributes in AD (a password > >>> change) > >>> > >>> dBCSPwd > >>> unicodePwd > >>> ntPwdHistory > >>> pwdLastSet > >>> supplementalCredentials > >>> lmPwdHistory > >>> > >>> and it will be up to some
From: Joe Richards [MVP] on 25 Jul 2006 19:38 1. Not if the person doing the rejoin doesn't have permissions in AD. This is a common config in large environments where very few people have rights. 2. http://technet2.microsoft.com/WindowsServer/en/library/0825816c-94e5-4a7f-be42-cbad6be4be501033.mspx?mfr=true Also in GPOs, Security Settings | Local Policies | Security Options | Domain Member:Maximum machine account password age. -- Joe Richards Microsoft MVP Windows Server Directory Services Author of O'Reilly Active Directory Third Edition www.joeware.net ---O'Reilly Active Directory Third Edition now available--- http://www.joeware.net/win/ad3e.htm Sasi wrote: > Thank both of you guys for your explanations. > some questions: > > 1.you know that you can rejoin a machine to the domain WITHOUT resetting its > account(provided that you have the permission to write some property on > computer object);so whats the point in reseting its account?isn't it useless? > > 2.about that refresh interval(30 days for win2k+ and 7 days for win2k-),how > can I change this default intervals?is it through a policy or AD should be > modified (ADSI edit and so on)? > > > "Herb Martin" wrote: > >> "Joe Richards [MVP]" <humorexpress(a)hotmail.com> wrote in message >> news:%23SoNTaQoGHA.4728(a)TK2MSFTNGP05.phx.gbl... >>> As for the relative insecurity, it entirely depends on the purpose of >>> adding the computer to the group and what access(es) it grants. The issue >>> comes in when you grant something that you want the computer to be able to >>> see but not the users and the users have physical access or any >> Ok, it doesn't really affect the cases where I would typical >> want to use or recommend it. >> >> Read access to shares that offer software intended to be >> deployed based on computer account. >> >> Such doesn't require perfect security, just practical control. >> >> -- >> Herb Martin, MCSE, MVP >> Accelerated MCSE >> http://www.LearnQuick.Com >> [phone number on web site] >> >> "Joe Richards [MVP]" <humorexpress(a)hotmail.com> wrote in message >> news:%23SoNTaQoGHA.4728(a)TK2MSFTNGP05.phx.gbl... >>> As for the relative insecurity, it entirely depends on the purpose of >>> adding the computer to the group and what access(es) it grants. The issue >>> comes in when you grant something that you want the computer to be able to >>> see but not the users and the users have physical access or any type of >>> access rights that allow launching a process in localsystem or >>> networkservice (or localservice if securing something local). Because at >>> that point, the person can gain access to a process running in one of >>> those contexts and will be running as the computer so will be able to see >>> the information that was supposed to be locked off. In general this >>> applies to users who are admins or power users but if someone ever got >>> access to control the settings for a service or the ability to modify the >>> info for a service then it is possible to escalate to the proper security >>> context. Also obviously, anyone with physical access can do it if they >>> want. >>> >>> Securing things like GPOs has limited use when doing this. Overall, I am >>> not a huge fan of group filtering, I have seen it go pretty bad on 3 >>> different occasions. One of those occasions happened to me when I applied >>> the GPO team's updates to the production domain and the ACL got wiped in >>> the process (the poorly written script blew out midstream) thereby >>> clearing the Group requirement which protected the GPO and thousands of >>> workstations and servers around the world locked down to kiosk mode. >>> >>> But anyway, say you set up a computer policy that all it does is set the >>> password on the admin account. You feel it is safe because you locked it >>> down so only the computers have access. There are two attack vectors: The >>> first is to impersonate a computer, that is easily accomplished if power >>> user or admin or you have physical access. The second is to set up a >>> network sniffer and just pull the batch file off the wire or the GPO off >>> the wire as it gets brought down to the PC. I used that once as a stepping >>> stone when doing a security check for a company several years ago and >>> within an hour had escalated myself all the way up to EA and sent an email >>> from the Chief of Security's mail account. The email recommended that the >>> consultant brought in to do a security check was amazing and should get >>> double his stated rate because he was so helpful. :) >>> >>> I thought about walking through what I did to compromise them but I think >>> it would do more harm than good. It generally isn't good to explain in >>> detail how someone can walk in off the street and compromise a corporate >>> network. Security is just far too lax in most companies, even those that >>> think or partially try to be secure including some very large major >>> companies. Most folks will often think they are secure because they think, >>> no one would ever do that, the consequences are too great if they get >>> caught (say like tailing someone through a secured outside door to a >>> building) but honestly, not everyone has the same value systems when >>> looking at doing things and there are people who would not even think >>> twice about stuff that most people would be far too scared to do because >>> they think, someone MUST be watching. The scary fact is, someone usually >>> isn't watching or is watching so poorly it is worthless. Secured doors are >>> worthless unless they physically only allow one person to pass at a time >>> or there is a security guard standing right there, anything else is >>> insecure and can be breached. Once inside... how well does your network >>> stand up? What rights do people have by default on workstations? In 90%+ >>> of the companies... Admin. That can be used right there to cause a heap of >>> trouble for most places. The larger the company, the more likely someone >>> could walk into the building and get to a logged in working PC with very >>> little to no issue or chance of being caught. >>> >>> joe >>> >>> -- >>> Joe Richards Microsoft MVP Windows Server Directory Services >>> Author of O'Reilly Active Directory Third Edition >>> www.joeware.net >>> >>> >>> ---O'Reilly Active Directory Third Edition n
From: Sasi on 27 Jul 2006 10:20
is this option also availabe in windows 2000? I don't have such option in my windows 2000 server security options. "Joe Richards [MVP]" wrote: > 1. Not if the person doing the rejoin doesn't have permissions in AD. > This is a common config in large environments where very few people have > rights. > > 2. > http://technet2.microsoft.com/WindowsServer/en/library/0825816c-94e5-4a7f-be42-cbad6be4be501033.mspx?mfr=true > > Also in GPOs, Security Settings | Local Policies | Security Options | > Domain Member:Maximum machine account password age. > > > > -- > Joe Richards Microsoft MVP Windows Server Directory Services > Author of O'Reilly Active Directory Third Edition > www.joeware.net > > > ---O'Reilly Active Directory Third Edition now available--- > > http://www.joeware.net/win/ad3e.htm > > > Sasi wrote: > > Thank both of you guys for your explanations. > > some questions: > > > > 1.you know that you can rejoin a machine to the domain WITHOUT resetting its > > account(provided that you have the permission to write some property on > > computer object);so whats the point in reseting its account?isn't it useless? > > > > 2.about that refresh interval(30 days for win2k+ and 7 days for win2k-),how > > can I change this default intervals?is it through a policy or AD should be > > modified (ADSI edit and so on)? > > > > > > "Herb Martin" wrote: > > > >> "Joe Richards [MVP]" <humorexpress(a)hotmail.com> wrote in message > >> news:%23SoNTaQoGHA.4728(a)TK2MSFTNGP05.phx.gbl... > >>> As for the relative insecurity, it entirely depends on the purpose of > >>> adding the computer to the group and what access(es) it grants. The issue > >>> comes in when you grant something that you want the computer to be able to > >>> see but not the users and the users have physical access or any > >> Ok, it doesn't really affect the cases where I would typical > >> want to use or recommend it. > >> > >> Read access to shares that offer software intended to be > >> deployed based on computer account. > >> > >> Such doesn't require perfect security, just practical control. > >> > >> -- > >> Herb Martin, MCSE, MVP > >> Accelerated MCSE > >> http://www.LearnQuick.Com > >> [phone number on web site] > >> > >> "Joe Richards [MVP]" <humorexpress(a)hotmail.com> wrote in message > >> news:%23SoNTaQoGHA.4728(a)TK2MSFTNGP05.phx.gbl... > >>> As for the relative insecurity, it entirely depends on the purpose of > >>> adding the computer to the group and what access(es) it grants. The issue > >>> comes in when you grant something that you want the computer to be able to > >>> see but not the users and the users have physical access or any type of > >>> access rights that allow launching a process in localsystem or > >>> networkservice (or localservice if securing something local). Because at > >>> that point, the person can gain access to a process running in one of > >>> those contexts and will be running as the computer so will be able to see > >>> the information that was supposed to be locked off. In general this > >>> applies to users who are admins or power users but if someone ever got > >>> access to control the settings for a service or the ability to modify the > >>> info for a service then it is possible to escalate to the proper security > >>> context. Also obviously, anyone with physical access can do it if they > >>> want. > >>> > >>> Securing things like GPOs has limited use when doing this. Overall, I am > >>> not a huge fan of group filtering, I have seen it go pretty bad on 3 > >>> different occasions. One of those occasions happened to me when I applied > >>> the GPO team's updates to the production domain and the ACL got wiped in > >>> the process (the poorly written script blew out midstream) thereby > >>> clearing the Group requirement which protected the GPO and thousands of > >>> workstations and servers around the world locked down to kiosk mode. > >>> > >>> But anyway, say you set up a computer policy that all it does is set the > >>> password on the admin account. You feel it is safe because you locked it > >>> down so only the computers have access. There are two attack vectors: The > >>> first is to impersonate a computer, that is easily accomplished if power > >>> user or admin or you have physical access. The second is to set up a > >>> network sniffer and just pull the batch file off the wire or the GPO off > >>> the wire as it gets brought down to the PC. I used that once as a stepping > >>> stone when doing a security check for a company several years ago and > >>> within an hour had escalated myself all the way up to EA and sent an email > >>> from the Chief of Security's mail account. The email recommended that the > >>> consultant brought in to do a security check was amazing and should get > >>> double his stated rate because he was so helpful. :) > >>> > >>> I thought about walking through what I did to compromise them but I think > >>> it would do more harm than good. It generally isn't good to explain in > >>> detail how someone can walk in off the street and compromise a corporate > >>> network. Security is just far too lax in most companies, even those that > >>> think or partially try to be secure including some very large major > >>> companies. Most folks will often think they are secure because they think, > >>> no one would ever do that, the consequences are too great if they get > >>> caught (say like tailing someone through a secured outside door to a > >>> building) but honestly, not everyone has the same value systems when > >>> looking at doing things and there are people who would not even think > >>> twice about stuff that most people would be far too scared to do because > >>> they think, someone MUST be watching. The scary fact is, someone usually > >>> isn't watching or is watching so poorly it is worthless. Secured doors are > >>> worthless unless they physically only allow one person to pass at a time > >>> or there is a security guard standing right there, anything else is > >>> insecure and can be breached. Once inside... how well does your network > >>> stand up? What rights do people have by default on workstations? In 90%+ > >>> of the companies... Admin. That can be used right there to cause a heap of > >>> trouble for most places. The larger the company, the |