SAMR Discovery Process

%3CLINGO-SUB%20id%3D%22lingo-sub-1486854%22%20slang%3D%22en-US%22%3ESAMR%20Discovery%20Process%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1486854%22%20slang%3D%22en-US%22%3E%3CP%3EFor%20the%20SAM-R%2C%20we%20understand%20the%20following%20is%20required%20%22Azure%20ATP%20lateral%20movement%20path%20detection%20relies%20on%20queries%20that%20identify%20local%20admins%20on%20specific%20machines.%20These%20queries%20are%20performed%20with%20the%20SAM-R%20protocol%2C%20using%20the%20Azure%20ATP%20Service%20account%20created%20during%20Azure%20ATP%20installation.%3CBR%20%2F%3E%3CBR%20%2F%3E%3CBR%20%2F%3EMy%20question%20is%20around%20the%20SAM-R%20process%20from%20the%20sensors%20to%20the%20domain%20members%20and%20network%20access%20rules%20(FW).%26nbsp%3B%20%26nbsp%3BOur%20AD%20site%20is%20a%20standard%20hub%20and%20spoke%20with%20several%20dozen%20branch%20office%20locations.%3CBR%20%2F%3E%3CBR%20%2F%3EWhat%20determines%20which%20ATP%20sensor%20is%20used%20to%20queries%20a%20domain%20members%3F%26nbsp%3B%3CBR%20%2F%3EDoes%20the%20Sensor%20only%20perform%20the%20SAMR%20discovery%20against%20the%20domain%20members%20in%20its%20AD%20site%20or%20some%20other%20discovery%20mechanism%3F%26nbsp%3B%3CBR%20%2F%3EDoes%20each%20domain%20sensor%20need%20SAM-R%2FSMB%20access%20to%20ALL%20domain%20members%3F%26nbsp%3B%26nbsp%3B%3CBR%20%2F%3E%3CBR%20%2F%3EExample%3A%3CBR%20%2F%3EAD-Branch1%20server%20only%20requires%20TCP445%20to%20networks%20in%26nbsp%3BBranch1.%3CBR%20%2F%3E%3CBR%20%2F%3E%3CBR%20%2F%3EThank%20you%3CBR%20%2F%3E%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1487340%22%20slang%3D%22en-US%22%3ERe%3A%20SAMR%20Discovery%20Process%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1487340%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F173807%22%20target%3D%22_blank%22%3E%40Bryan%20Bishop%3C%2FA%3E%26nbsp%3B%20Some%20clarifications%3A%3C%2FP%3E%0A%3CP%3E-%20the%20account%20use%20to%20authenticate%20with%20those%20SAMR%20requests%20is%20not%20the%20service%20account%20%2C%20but%20the%20configured%20AD%2Fgmsa%20account%20in%20th%20eportal.%3C%2FP%3E%0A%3CP%3EA%20sensor%20might%20issue%20the%20inquiry%20to%20any%20endpoint%20that%20contacted%20the%20DC%20it%20is%20installed%20on%2C%20no%20matter%20where%20it%20is%20located.%3CBR%20%2F%3ESo%20all%20sensors%20need%20port%20access%26nbsp%3B%20to%20all%20endpoints%20in%20the%20network.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1487711%22%20slang%3D%22en-US%22%3ERe%3A%20SAMR%20Discovery%20Process%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1487711%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F106935%22%20target%3D%22_blank%22%3E%40Eli%20Ofek%3C%2FA%3E%26nbsp%3BThanks%20for%20the%20reply!%3CBR%20%2F%3E%3CBR%20%2F%3ECorrect%2C%20the%20gMSA%20will%20be%20used.%26nbsp%3B%26nbsp%3B%3CBR%20%2F%3E%3CBR%20%2F%3EWe%20have%20a%20highly%20segmented%20environment.%26nbsp%3B%20%26nbsp%3BA%20DC%20in%20BO%231%20is%20not%20permitted%20to%20access%20a%20domain%20member%20in%20BO%232%2C%20firewall%20rules.%26nbsp%3B%20%26nbsp%3BWe%20to%20allow%20domain%20members%20in%20a%20site%20access%20to%20the%20DC%20in%20that%20site%20and%20the%20DCs%20in%20our%20hub%20site.%26nbsp%3B%20If%20I%20understand%20your%20reply%2C%20we%20won't%20have%20any%20issues%20since%20a%20DC%20in%20BO%232%20will%20never%20authenticate%20a%20endpoint%20in%20BO%233%2C%20no%20firewall%20rules.%3CBR%20%2F%3E%3CBR%20%2F%3EIn%20a%20multiple%20domain%20forest%2C%20the%20sensors%20only%20perform%20this%20SAMR%20function%20within%20the%20DC's%20server%20domain%2C%20right%3F%26nbsp%3B%3CBR%20%2F%3E%3CBR%20%2F%3E%3CBR%20%2F%3E%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1489079%22%20slang%3D%22en-US%22%3ERe%3A%20SAMR%20Discovery%20Process%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1489079%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F173807%22%20target%3D%22_blank%22%3E%40Bryan%20Bishop%3C%2FA%3E%26nbsp%3BNO%2C%20SMAR%20inquiry%20attempt%26nbsp%3B%20is%20a%20response%20to%20any%20endpoint%20that%20contacts%20the%20DC%2C%20no%20matter%20where%20it%20is.%20if%20effectively%20you%20don't%20have%20cross%20domain%2Fcross%20forests%20communication%2C%20then%20effectively%20it%20won't%20happen.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1490016%22%20slang%3D%22en-US%22%3ERe%3A%20SAMR%20Discovery%20Process%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1490016%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F106935%22%20target%3D%22_blank%22%3E%40Eli%20Ofek%3C%2FA%3E%26nbsp%3B%3CBR%20%2F%3E%3CBR%20%2F%3EHi%3CBR%20%2F%3E%3CBR%20%2F%3EPerhaps%20I'm%20not%20explaining%20myself%20correctly.%26nbsp%3B%26nbsp%3B%3CBR%20%2F%3E%3CBR%20%2F%3ECL1%20resides%20in%20BO1%20and%20has%20network%20rules%20to%20authenticate%20to%20BODC1%2C%20BHDC1%2CBHDC2%2CBHDC3%20but%20will%20not%20have%20network%20access%20to%26nbsp%3BBODC2.%26nbsp%3B%20Therefore%2C%20CL1%20will%20never%20authenticate%20to%20BODC1.%3CBR%20%2F%3E%3CBR%20%2F%3EIn%20this%20scenario%2C%20you%20are%20stating%20that%20BODC1%20still%20requires%20network%20access%20to%20CL1%20located%20in%20BO1%3F%3CBR%20%2F%3E%3CBR%20%2F%3E%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1494292%22%20slang%3D%22en-US%22%3ERe%3A%20SAMR%20Discovery%20Process%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1494292%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F173807%22%20target%3D%22_blank%22%3E%40Bryan%20Bishop%3C%2FA%3E%26nbsp%3B%20If%26nbsp%3B%3CSPAN%3EBODC1%26nbsp%3B%20never%20sees%20network%20traffic%20from%20CL1%2C%20then%20it%20will%20never%20try%20to%20actively%20contact%20it.%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E
Contributor

For the SAM-R, we understand the following is required "Azure ATP lateral movement path detection relies on queries that identify local admins on specific machines. These queries are performed with the SAM-R protocol, using the Azure ATP Service account created during Azure ATP installation.


My question is around the SAM-R process from the sensors to the domain members and network access rules (FW).   Our AD site is a standard hub and spoke with several dozen branch office locations.

What determines which ATP sensor is used to queries a domain members? 
Does the Sensor only perform the SAMR discovery against the domain members in its AD site or some other discovery mechanism? 
Does each domain sensor need SAM-R/SMB access to ALL domain members?  

Example:
AD-Branch1 server only requires TCP445 to networks in Branch1.


Thank you


 

5 Replies

@Bryan Bishop  Some clarifications:

- the account use to authenticate with those SAMR requests is not the service account , but the configured AD/gmsa account in th eportal.

A sensor might issue the inquiry to any endpoint that contacted the DC it is installed on, no matter where it is located.
So all sensors need port access  to all endpoints in the network.

@Eli Ofek Thanks for the reply!

Correct, the gMSA will be used.  

We have a highly segmented environment.   A DC in BO#1 is not permitted to access a domain member in BO#2, firewall rules.   We to allow domain members in a site access to the DC in that site and the DCs in our hub site.  If I understand your reply, we won't have any issues since a DC in BO#2 will never authenticate a endpoint in BO#3, no firewall rules.

In a multiple domain forest, the sensors only perform this SAMR function within the DC's server domain, right? 




 

 

@Bryan Bishop NO, SMAR inquiry attempt  is a response to any endpoint that contacts the DC, no matter where it is. if effectively you don't have cross domain/cross forests communication, then effectively it won't happen.

@Eli Ofek 

Hi

Perhaps I'm not explaining myself correctly.  

CL1 resides in BO1 and has network rules to authenticate to BODC1, BHDC1,BHDC2,BHDC3 but will not have network access to BODC2.  Therefore, CL1 will never authenticate to BODC1.

In this scenario, you are stating that BODC1 still requires network access to CL1 located in BO1?



 

@Bryan Bishop  If BODC1  never sees network traffic from CL1, then it will never try to actively contact it.