USER-ID and problems with runas /netonly in combination with MMC modules

Reply
L0 Member

USER-ID and problems with runas /netonly in combination with MMC modules

Hello, 

 

as a safety measure i placed my workstation in a different vlan and from there i'm managing our network and servers which are located in the designated dedicated vlans. 

 

On the firewall we have a rule which makes it possible for our 'admin' accounts to access most vlans for management tasks. 

 

Now when i use runas for certain management tools and use my admin credentials the runas command takes over the AD account and from thereon the firewall binds my ip to my admin account and so all traffic goes over the 'admin firewall rules' which is not optimal obviously. 

 

I've came accross the 'runas /netonly' option which is perfect for remote management but i'm running into problems with this trick. 

 

As soon as i use this for MMC modules for example dsa.msc it seems the firewall again binds the admin account to my ip address.. 

If i use runas /netonly for different application it doesn't. 

 

is there any workaround for this phenomena? 

 

thanks!

Tags (3)
L4 Transporter

Re: USER-ID and problems with runas /netonly in combination with MMC modules

Not an exact fix, but an idea that I have seen other customer use, is to reduce the time of the caching of IP info from the default 45 minutes, so something less, say 5 minutes.  There may be a potential that more IPs may be cached out, but it may be an idea/temp workaround (if even called that).  

 

Unless there was scripting function that after you did the netas command you would also have it clear the IP mapping for your username, that is about the only thing (knee jerk reaction) that comes to mind to perhaps assist you.

 

Thanks.

 

L7 Applicator

Re: USER-ID and problems with runas /netonly in combination with MMC modules

Hello,

I'm going to guess that you are using DC logs for your mappings? We had other issues that management didnt like, i.e. user names showing up on blocked traffic where a specific user was the last to log into the server. To get around this, we changed our method to use Exchange logs instead. We no longer have user-id from the servers subnets, but we dont require them there.

 

Just another thought.

 

Regards,

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!