Alerts for uptake of Azure Virtual Desktop etc

%3CLINGO-SUB%20id%3D%22lingo-sub-2752313%22%20slang%3D%22en-US%22%3EAlerts%20for%20uptake%20of%20Azure%20Virtual%20Desktop%20etc%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2752313%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20all%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EJust%20wondering%20what%20to%20do%20to%20get%20MDI%20to%20apply%20some%20basic%20intelligence%20to%20account%20alerts.%20We%20(and%20many%20customers)%20have%20been%20deploying%20services%20like%20Azure%20Virtual%20Desktop%20over%20recent%20months.%20These%20are%20used%20for%20ad-hoc%20access%20to%20legacy%20on-prem%20services.%20As%20a%20result%20MDI%2FMCAS%20turns%20into%20a%20stream%20of%20risky%20logon%20spam.%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAll%20the%20AVD%20virtual%20machines%20are%20hybrid%20joined%20and%20compliant.%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20can't%20exclude%2Ftrust%20the%20source%20IP%20as%20it%20is%20dozens%20of%20Azure%20data%20centre%20outbound%20IP%20locations%20and%20shared%20amongst%20random%20tenants.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20was%20wondering%20about%20setting%20the%20AVD%20azure%20vnet%20as%20a%20trusted%20location%2C%20I%20don't%20like%20to%20do%20this%20as%20a%20user%20or%20intruder%20just%20needs%20to%20happen%20to%20use%20the%20same%20subnet%20on%20their%20internal%20network%20and%20treats%20it%20as%20trusted.%20This%20would%20be%20for%20MCAS%20and%20I'm%20not%20sure%20that%20would%20have%20any%20impact%20on%20MDI%20risky%20sign-ins.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20can't%20see%20a%20way%20to%20tell%20MDI%20that%20access%20from%20virtual%20desktop%20is%20fairly%20trusted%2C%20the%20access%20being%20intermittent%20and%20ad-hoc%20seems%20to%20be%20preventing%20it%20from%20learning%20that%20these%20are%20'internal%20systems'.%20With%20Windows%20365%20and%20continued%20uptake%20of%20AVD%20I%20can%20see%20this%20getting%20much%20worse%20to%20the%20point%20where%20genuine%20sign-in%20risk%20just%20gets%20lost%20in%20the%20sea%20of%20virtual%20desktop%20spam.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EGuidance%20and%20experience%20appreciated.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EPete%3C%2FP%3E%3C%2FLINGO-BODY%3E
Contributor

Hi all,

 

Just wondering what to do to get MDI to apply some basic intelligence to account alerts. We (and many customers) have been deploying services like Azure Virtual Desktop over recent months. These are used for ad-hoc access to legacy on-prem services. As a result MDI/MCAS turns into a stream of risky logon spam. 

 

All the AVD virtual machines are hybrid joined and compliant. 

 

I can't exclude/trust the source IP as it is dozens of Azure data centre outbound IP locations and shared amongst random tenants.

 

I was wondering about setting the AVD azure vnet as a trusted location, I don't like to do this as a user or intruder just needs to happen to use the same subnet on their internal network and treats it as trusted. This would be for MCAS and I'm not sure that would have any impact on MDI risky sign-ins.

 

I can't see a way to tell MDI that access from virtual desktop is fairly trusted, the access being intermittent and ad-hoc seems to be preventing it from learning that these are 'internal systems'. With Windows 365 and continued uptake of AVD I can see this getting much worse to the point where genuine sign-in risk just gets lost in the sea of virtual desktop spam.

 

Guidance and experience appreciated.

 

Pete

0 Replies
www.000webhost.com