Multiple Windows Domains
-
Good morning CPers, haven't been round these parts for a while but I return today with a dull question: Have you worked in an environment where there are multiple windows domains? Until recently I've never needed to mess with that drop down on the login box below your username and password where you state the domain, as its always the same and is the same for the whole company. I'm now being exposed to the idea that you put your development, UAT and Production environments in different domains, and you need different credentials for each. In practice this means doing odd stuff like running visual studio 'impersonating' a different account (runas I think). You can see the broad purpose, to fully isolate the environments but of course there has to be 'doors' to allow the software to propagate towards prod. Anyone done this? Good or bad?
Regards, Rob Philpott.
-
Good morning CPers, haven't been round these parts for a while but I return today with a dull question: Have you worked in an environment where there are multiple windows domains? Until recently I've never needed to mess with that drop down on the login box below your username and password where you state the domain, as its always the same and is the same for the whole company. I'm now being exposed to the idea that you put your development, UAT and Production environments in different domains, and you need different credentials for each. In practice this means doing odd stuff like running visual studio 'impersonating' a different account (runas I think). You can see the broad purpose, to fully isolate the environments but of course there has to be 'doors' to allow the software to propagate towards prod. Anyone done this? Good or bad?
Regards, Rob Philpott.
I did this by accident after our company changed the domain, I kept working in the old domain which was not very limited. Eventually however my "cheating" was discovered and measures were taken to prevent this :-\
-
Good morning CPers, haven't been round these parts for a while but I return today with a dull question: Have you worked in an environment where there are multiple windows domains? Until recently I've never needed to mess with that drop down on the login box below your username and password where you state the domain, as its always the same and is the same for the whole company. I'm now being exposed to the idea that you put your development, UAT and Production environments in different domains, and you need different credentials for each. In practice this means doing odd stuff like running visual studio 'impersonating' a different account (runas I think). You can see the broad purpose, to fully isolate the environments but of course there has to be 'doors' to allow the software to propagate towards prod. Anyone done this? Good or bad?
Regards, Rob Philpott.
Our Test, QA, and production domains (we call these the "plus side") all use windows authentication (and they're separate domains), and we have 2FA (a card that goes into a card reader, and a pin code). Only our dev environment requires a password (access card doesn't work on dev). We can't run vis studio on any domain except dev. On the plus side domains, we can't use the dev console in the browser (it's disabled), which has forced me to "take steps" by putting pages on our app that only devs can see.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
Our Test, QA, and production domains (we call these the "plus side") all use windows authentication (and they're separate domains), and we have 2FA (a card that goes into a card reader, and a pin code). Only our dev environment requires a password (access card doesn't work on dev). We can't run vis studio on any domain except dev. On the plus side domains, we can't use the dev console in the browser (it's disabled), which has forced me to "take steps" by putting pages on our app that only devs can see.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013But what happens when you need to sort some production issue out which, say, involves examining production logs and your tail program (/development arsenal) is in another domain?
Regards, Rob Philpott.
-
But what happens when you need to sort some production issue out which, say, involves examining production logs and your tail program (/development arsenal) is in another domain?
Regards, Rob Philpott.
Well, we don't. We have to involve a dba (for some reason, they have admin rights on the web servers) to look at things like the system log. For our web apps, we have to try to determine what's happening by looking at the problem on the dev side. 0) All four environments have different hardware configurations (memory, disk space, cores, and number of servers on the farm). 1) It's almost impossible to determine the cause of a problem. We also have sys admins that apply patches that may/may not affect the operation of IIS. Tthis has bitten us at least twice, where we had to actually modify our code to get around the new "security" restrictions. 2) We are subject to the whims of our "authoritative data sources", where our data pulls may or may not work (connectivity issues, internet outage issues, data that changes format, etc). Of course, it's up to the devs to prove it's not the code. This is exacerbated by the fact that the dev environment has NO ACCESS to the internet at all, meaning we cannot actually do a data pull in that environment, meaning we have to have a DBA do it on an environment we can't log onto. 3) We have an insane program manager that has prohibited us from sucking data off the plus side and putting it onto the dev side, so we secretly backup production data, and put it onto dev one table at a time (we can't do a restore because it will overwrite work in progress stored procs. 4) The dev-only pages I've recently added to the app allow us to circumvent the need to suck data or restore from backup most of the time. 5) Last year, we updated vis studio to 2017 (from 2015). We can't update any further because we can't get a non-web installer (from what I've been told), and as I've already stated, we have no internet access. This also means we can't get to NuGet... 6) To save money (we get charged a certain amount for every 15 minutes our dev environment is running, even if nobody is using it), our entire dev environment is shutdown on weekends and holidays, so even if we wanted to work on a weekend day, we can't. Our dev experience where I work sucks big hairy donkey testicles... I actually hate it. It doesn't help that our program manager has taken on the duties of scrum manager and dev team lead - and he has exactly ZERO experience as a developer.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never h -
Well, we don't. We have to involve a dba (for some reason, they have admin rights on the web servers) to look at things like the system log. For our web apps, we have to try to determine what's happening by looking at the problem on the dev side. 0) All four environments have different hardware configurations (memory, disk space, cores, and number of servers on the farm). 1) It's almost impossible to determine the cause of a problem. We also have sys admins that apply patches that may/may not affect the operation of IIS. Tthis has bitten us at least twice, where we had to actually modify our code to get around the new "security" restrictions. 2) We are subject to the whims of our "authoritative data sources", where our data pulls may or may not work (connectivity issues, internet outage issues, data that changes format, etc). Of course, it's up to the devs to prove it's not the code. This is exacerbated by the fact that the dev environment has NO ACCESS to the internet at all, meaning we cannot actually do a data pull in that environment, meaning we have to have a DBA do it on an environment we can't log onto. 3) We have an insane program manager that has prohibited us from sucking data off the plus side and putting it onto the dev side, so we secretly backup production data, and put it onto dev one table at a time (we can't do a restore because it will overwrite work in progress stored procs. 4) The dev-only pages I've recently added to the app allow us to circumvent the need to suck data or restore from backup most of the time. 5) Last year, we updated vis studio to 2017 (from 2015). We can't update any further because we can't get a non-web installer (from what I've been told), and as I've already stated, we have no internet access. This also means we can't get to NuGet... 6) To save money (we get charged a certain amount for every 15 minutes our dev environment is running, even if nobody is using it), our entire dev environment is shutdown on weekends and holidays, so even if we wanted to work on a weekend day, we can't. Our dev experience where I work sucks big hairy donkey testicles... I actually hate it. It doesn't help that our program manager has taken on the duties of scrum manager and dev team lead - and he has exactly ZERO experience as a developer.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never hOoph, tough read. Sounds like a human rights violation. It amazes the the way they throw so many hurdles at developers. No internet in dev, just what the hell is that? And part (3) rings bells and strikes me as madness. There are those who hold the opinion that developers should not see the data they work with. How that can ever work... I'll surmise the general tone as being 'not good' in respect of distinct domains then. Thanks for the lengthy response!
Regards, Rob Philpott.
-
Ooph, tough read. Sounds like a human rights violation. It amazes the the way they throw so many hurdles at developers. No internet in dev, just what the hell is that? And part (3) rings bells and strikes me as madness. There are those who hold the opinion that developers should not see the data they work with. How that can ever work... I'll surmise the general tone as being 'not good' in respect of distinct domains then. Thanks for the lengthy response!
Regards, Rob Philpott.
Separate domains could be okay if they'd at least create an active directory group for developers on the plus side that allowed us to get the dev console in the browser, and gave us read-only access to the databases, but evidently, those things are a security no-no.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
Well, we don't. We have to involve a dba (for some reason, they have admin rights on the web servers) to look at things like the system log. For our web apps, we have to try to determine what's happening by looking at the problem on the dev side. 0) All four environments have different hardware configurations (memory, disk space, cores, and number of servers on the farm). 1) It's almost impossible to determine the cause of a problem. We also have sys admins that apply patches that may/may not affect the operation of IIS. Tthis has bitten us at least twice, where we had to actually modify our code to get around the new "security" restrictions. 2) We are subject to the whims of our "authoritative data sources", where our data pulls may or may not work (connectivity issues, internet outage issues, data that changes format, etc). Of course, it's up to the devs to prove it's not the code. This is exacerbated by the fact that the dev environment has NO ACCESS to the internet at all, meaning we cannot actually do a data pull in that environment, meaning we have to have a DBA do it on an environment we can't log onto. 3) We have an insane program manager that has prohibited us from sucking data off the plus side and putting it onto the dev side, so we secretly backup production data, and put it onto dev one table at a time (we can't do a restore because it will overwrite work in progress stored procs. 4) The dev-only pages I've recently added to the app allow us to circumvent the need to suck data or restore from backup most of the time. 5) Last year, we updated vis studio to 2017 (from 2015). We can't update any further because we can't get a non-web installer (from what I've been told), and as I've already stated, we have no internet access. This also means we can't get to NuGet... 6) To save money (we get charged a certain amount for every 15 minutes our dev environment is running, even if nobody is using it), our entire dev environment is shutdown on weekends and holidays, so even if we wanted to work on a weekend day, we can't. Our dev experience where I work sucks big hairy donkey testicles... I actually hate it. It doesn't help that our program manager has taken on the duties of scrum manager and dev team lead - and he has exactly ZERO experience as a developer.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never hThe Joys of working for the DoD (if I am remembering correctly) and we have a similar setup since we deal with the US Govt, including DoD. Separate VPN to work on the Gov stuff which cuts off all communications with the rest of the org.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
-
Well, we don't. We have to involve a dba (for some reason, they have admin rights on the web servers) to look at things like the system log. For our web apps, we have to try to determine what's happening by looking at the problem on the dev side. 0) All four environments have different hardware configurations (memory, disk space, cores, and number of servers on the farm). 1) It's almost impossible to determine the cause of a problem. We also have sys admins that apply patches that may/may not affect the operation of IIS. Tthis has bitten us at least twice, where we had to actually modify our code to get around the new "security" restrictions. 2) We are subject to the whims of our "authoritative data sources", where our data pulls may or may not work (connectivity issues, internet outage issues, data that changes format, etc). Of course, it's up to the devs to prove it's not the code. This is exacerbated by the fact that the dev environment has NO ACCESS to the internet at all, meaning we cannot actually do a data pull in that environment, meaning we have to have a DBA do it on an environment we can't log onto. 3) We have an insane program manager that has prohibited us from sucking data off the plus side and putting it onto the dev side, so we secretly backup production data, and put it onto dev one table at a time (we can't do a restore because it will overwrite work in progress stored procs. 4) The dev-only pages I've recently added to the app allow us to circumvent the need to suck data or restore from backup most of the time. 5) Last year, we updated vis studio to 2017 (from 2015). We can't update any further because we can't get a non-web installer (from what I've been told), and as I've already stated, we have no internet access. This also means we can't get to NuGet... 6) To save money (we get charged a certain amount for every 15 minutes our dev environment is running, even if nobody is using it), our entire dev environment is shutdown on weekends and holidays, so even if we wanted to work on a weekend day, we can't. Our dev experience where I work sucks big hairy donkey testicles... I actually hate it. It doesn't help that our program manager has taken on the duties of scrum manager and dev team lead - and he has exactly ZERO experience as a developer.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never h#realJSOP wrote:
- We have an insane program manager that has prohibited us from sucking data off the plus side and putting it onto the dev side, so we secretly backup production data, and put it onto dev one table at a time
Knowing your end customer is the DOD, I really hope this isn't what it sounds like. While room, board, and most other amenities are provided at no cost to you; Club Fed is a really lousy place to retire to. :doh:
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius
-
The Joys of working for the DoD (if I am remembering correctly) and we have a similar setup since we deal with the US Govt, including DoD. Separate VPN to work on the Gov stuff which cuts off all communications with the rest of the org.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
We have a VPN to the org (from home).
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
Good morning CPers, haven't been round these parts for a while but I return today with a dull question: Have you worked in an environment where there are multiple windows domains? Until recently I've never needed to mess with that drop down on the login box below your username and password where you state the domain, as its always the same and is the same for the whole company. I'm now being exposed to the idea that you put your development, UAT and Production environments in different domains, and you need different credentials for each. In practice this means doing odd stuff like running visual studio 'impersonating' a different account (runas I think). You can see the broad purpose, to fully isolate the environments but of course there has to be 'doors' to allow the software to propagate towards prod. Anyone done this? Good or bad?
Regards, Rob Philpott.
Rob Philpott wrote:
I'm now being exposed to the idea that you put your development, UAT and Production environments in different domains,
That sounds to me like a nightmare. Why domains? Why not have UAT and production on separate servers?
Latest Article:
Create a Digital Ocean Droplet for .NET Core Web API with a real SSL Certificate on a Domain -
Rob Philpott wrote:
I'm now being exposed to the idea that you put your development, UAT and Production environments in different domains,
That sounds to me like a nightmare. Why domains? Why not have UAT and production on separate servers?
Latest Article:
Create a Digital Ocean Droplet for .NET Core Web API with a real SSL Certificate on a DomainI think they're perceived as units isolated from each other with the expectation that provides some level of security, but its all on the same network at the end of the day. I would think a lots of threats would be at network level, not the domain but to be honest I just don't know. Having thus far only ever worked on a single domain I don't really fully understand what it achieves or tries to by spanning domains. The closest I've been is a place where they had two physical networks, two PCs and a KVM switch on each desk "Prod" and "Dev". We couldn't get to our email on on Dev, only on prod. And on prod we couldn't get to our code. Infuriating. That place doesn't exist any longer it got taken over and sucked up into an economic black hole in 2008.
Regards, Rob Philpott.
-
Good morning CPers, haven't been round these parts for a while but I return today with a dull question: Have you worked in an environment where there are multiple windows domains? Until recently I've never needed to mess with that drop down on the login box below your username and password where you state the domain, as its always the same and is the same for the whole company. I'm now being exposed to the idea that you put your development, UAT and Production environments in different domains, and you need different credentials for each. In practice this means doing odd stuff like running visual studio 'impersonating' a different account (runas I think). You can see the broad purpose, to fully isolate the environments but of course there has to be 'doors' to allow the software to propagate towards prod. Anyone done this? Good or bad?
Regards, Rob Philpott.
My company uses separate subdomains for production and non-production. Non-production includes dev, QA, and RC/UAT environments. The subdomains are firewalled, so that non-production cannot reach production and vice versa. They adopted Microsoft's "privileged access workstation" guidance, where each user is assigned a laptop that is completely locked down (can't install anything, etc.), and that laptop hosts a VM (hosted locally) where we can do internet & email but not much else. Additionally, each user is assigned a production VM and a non-production VM (each hosted remotely). Developers have local admin privileges on the non-production VM, but are encouraged to limit software installed on it to whatever is available in our corporate Software Center hub. None of this is terrible by itself, and all makes sense to me security-wise. but here lies the problem: 1) each device and VM needs a separate login with a distinct password 2) the PAW laptop needs to be connected to the VPN, requiring a 2fa login 3) the "productivity" VM (the locally-hosted one) needs a separate VPN connection (requiring a second 2fa login) 4) the VPN connections time out, and I often need to re-connect multiple times daily 5) all 4 Windows logins (PAW device, productivity VM, non-prod VM, prod VM) are subject to password rotation, with stringent password complexity requirements 6) all devices and VMs lock out after just 3 minutes of inactivity 6) the PAW laptop is bitlocker-ed, so you need to enter a decryption code each time you reboot (which is frequent, since updates are pushed multiple times per week) The net result is that I spend a ridiculous proportion of my day typing in passwords, which I have no recourse but to write down because there's no way in heck I can remember umpteen different passwords that change every several weeks. By the time I've caught up on email, or responded to a chat thread with my colleagues, or finished reading a CP article, my non-prod VM has almost certainly locked out, and then after spending a little time writing code, I head over to my "productivity" VM to check something on StackOverflow and oops! It's locked out by now and I have to log in again (what was that password [checks notebook]?). It's a total productivity-killer!
-
My company uses separate subdomains for production and non-production. Non-production includes dev, QA, and RC/UAT environments. The subdomains are firewalled, so that non-production cannot reach production and vice versa. They adopted Microsoft's "privileged access workstation" guidance, where each user is assigned a laptop that is completely locked down (can't install anything, etc.), and that laptop hosts a VM (hosted locally) where we can do internet & email but not much else. Additionally, each user is assigned a production VM and a non-production VM (each hosted remotely). Developers have local admin privileges on the non-production VM, but are encouraged to limit software installed on it to whatever is available in our corporate Software Center hub. None of this is terrible by itself, and all makes sense to me security-wise. but here lies the problem: 1) each device and VM needs a separate login with a distinct password 2) the PAW laptop needs to be connected to the VPN, requiring a 2fa login 3) the "productivity" VM (the locally-hosted one) needs a separate VPN connection (requiring a second 2fa login) 4) the VPN connections time out, and I often need to re-connect multiple times daily 5) all 4 Windows logins (PAW device, productivity VM, non-prod VM, prod VM) are subject to password rotation, with stringent password complexity requirements 6) all devices and VMs lock out after just 3 minutes of inactivity 6) the PAW laptop is bitlocker-ed, so you need to enter a decryption code each time you reboot (which is frequent, since updates are pushed multiple times per week) The net result is that I spend a ridiculous proportion of my day typing in passwords, which I have no recourse but to write down because there's no way in heck I can remember umpteen different passwords that change every several weeks. By the time I've caught up on email, or responded to a chat thread with my colleagues, or finished reading a CP article, my non-prod VM has almost certainly locked out, and then after spending a little time writing code, I head over to my "productivity" VM to check something on StackOverflow and oops! It's locked out by now and I have to log in again (what was that password [checks notebook]?). It's a total productivity-killer!
-
Good morning CPers, haven't been round these parts for a while but I return today with a dull question: Have you worked in an environment where there are multiple windows domains? Until recently I've never needed to mess with that drop down on the login box below your username and password where you state the domain, as its always the same and is the same for the whole company. I'm now being exposed to the idea that you put your development, UAT and Production environments in different domains, and you need different credentials for each. In practice this means doing odd stuff like running visual studio 'impersonating' a different account (runas I think). You can see the broad purpose, to fully isolate the environments but of course there has to be 'doors' to allow the software to propagate towards prod. Anyone done this? Good or bad?
Regards, Rob Philpott.
You could use trusts between those domains to enable your "normal" user to be able to do stuff on the developement and UAT domain, but tbh working on different domains just sucks. It adds a lot of overhead so there has to be a really good reason to go through that kind of trouble. Until now I have only seen different domains trusting each other in cases of different companies working together in some sort. I also saw people having multiple devices to work on different domains but that sucks a lot too. Imagine carrying 2 laptops with you all the time.. or in your case: 3. What you could do is set up several computers in the dev and uat domain and login on those devices via RDP using users from those respective domains. But that's all meh.
-
Good morning CPers, haven't been round these parts for a while but I return today with a dull question: Have you worked in an environment where there are multiple windows domains? Until recently I've never needed to mess with that drop down on the login box below your username and password where you state the domain, as its always the same and is the same for the whole company. I'm now being exposed to the idea that you put your development, UAT and Production environments in different domains, and you need different credentials for each. In practice this means doing odd stuff like running visual studio 'impersonating' a different account (runas I think). You can see the broad purpose, to fully isolate the environments but of course there has to be 'doors' to allow the software to propagate towards prod. Anyone done this? Good or bad?
Regards, Rob Philpott.
A long, long time ago (10+ years?) I set my personal laptop up with a work domain separate from my home domain. I don’t recall any specific problems with doing so, but I think it felt a bit clunky. I remember having to set different themes so I could tell at-a-glance which environment I was logged in to. It’s worth a try,if only to satisfy your curiosity. :thumbsup:
Time is the differentiation of eternity devised by man to measure the passage of human events. - Manly P. Hall Mark Just another cog in the wheel
-
My company uses separate subdomains for production and non-production. Non-production includes dev, QA, and RC/UAT environments. The subdomains are firewalled, so that non-production cannot reach production and vice versa. They adopted Microsoft's "privileged access workstation" guidance, where each user is assigned a laptop that is completely locked down (can't install anything, etc.), and that laptop hosts a VM (hosted locally) where we can do internet & email but not much else. Additionally, each user is assigned a production VM and a non-production VM (each hosted remotely). Developers have local admin privileges on the non-production VM, but are encouraged to limit software installed on it to whatever is available in our corporate Software Center hub. None of this is terrible by itself, and all makes sense to me security-wise. but here lies the problem: 1) each device and VM needs a separate login with a distinct password 2) the PAW laptop needs to be connected to the VPN, requiring a 2fa login 3) the "productivity" VM (the locally-hosted one) needs a separate VPN connection (requiring a second 2fa login) 4) the VPN connections time out, and I often need to re-connect multiple times daily 5) all 4 Windows logins (PAW device, productivity VM, non-prod VM, prod VM) are subject to password rotation, with stringent password complexity requirements 6) all devices and VMs lock out after just 3 minutes of inactivity 6) the PAW laptop is bitlocker-ed, so you need to enter a decryption code each time you reboot (which is frequent, since updates are pushed multiple times per week) The net result is that I spend a ridiculous proportion of my day typing in passwords, which I have no recourse but to write down because there's no way in heck I can remember umpteen different passwords that change every several weeks. By the time I've caught up on email, or responded to a chat thread with my colleagues, or finished reading a CP article, my non-prod VM has almost certainly locked out, and then after spending a little time writing code, I head over to my "productivity" VM to check something on StackOverflow and oops! It's locked out by now and I have to log in again (what was that password [checks notebook]?). It's a total productivity-killer!
That's the point where you should get a stand alone tap to start/stop timer, record the amount of time you waste each day playing stupid password games; and charge it to IT overhead on your time sheet each day.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius
-
Well, we don't. We have to involve a dba (for some reason, they have admin rights on the web servers) to look at things like the system log. For our web apps, we have to try to determine what's happening by looking at the problem on the dev side. 0) All four environments have different hardware configurations (memory, disk space, cores, and number of servers on the farm). 1) It's almost impossible to determine the cause of a problem. We also have sys admins that apply patches that may/may not affect the operation of IIS. Tthis has bitten us at least twice, where we had to actually modify our code to get around the new "security" restrictions. 2) We are subject to the whims of our "authoritative data sources", where our data pulls may or may not work (connectivity issues, internet outage issues, data that changes format, etc). Of course, it's up to the devs to prove it's not the code. This is exacerbated by the fact that the dev environment has NO ACCESS to the internet at all, meaning we cannot actually do a data pull in that environment, meaning we have to have a DBA do it on an environment we can't log onto. 3) We have an insane program manager that has prohibited us from sucking data off the plus side and putting it onto the dev side, so we secretly backup production data, and put it onto dev one table at a time (we can't do a restore because it will overwrite work in progress stored procs. 4) The dev-only pages I've recently added to the app allow us to circumvent the need to suck data or restore from backup most of the time. 5) Last year, we updated vis studio to 2017 (from 2015). We can't update any further because we can't get a non-web installer (from what I've been told), and as I've already stated, we have no internet access. This also means we can't get to NuGet... 6) To save money (we get charged a certain amount for every 15 minutes our dev environment is running, even if nobody is using it), our entire dev environment is shutdown on weekends and holidays, so even if we wanted to work on a weekend day, we can't. Our dev experience where I work sucks big hairy donkey testicles... I actually hate it. It doesn't help that our program manager has taken on the duties of scrum manager and dev team lead - and he has exactly ZERO experience as a developer.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never hHi all, I quit a job cause of this kind of "unbelievable" restrictions...
If there is no solution, there is no problem !
-
Good morning CPers, haven't been round these parts for a while but I return today with a dull question: Have you worked in an environment where there are multiple windows domains? Until recently I've never needed to mess with that drop down on the login box below your username and password where you state the domain, as its always the same and is the same for the whole company. I'm now being exposed to the idea that you put your development, UAT and Production environments in different domains, and you need different credentials for each. In practice this means doing odd stuff like running visual studio 'impersonating' a different account (runas I think). You can see the broad purpose, to fully isolate the environments but of course there has to be 'doors' to allow the software to propagate towards prod. Anyone done this? Good or bad?
Regards, Rob Philpott.
We have a production domain, a dmz domain and a dev domain. There are one way trusts so that dmz trusts prod and dev trusts prod, but not the other way. We just use prod ids on all domains. If a dmz or dev box is compromised, it is supposed to slow down sideways propagation into prod.