Posts by The Vociferous Time Waster 611 posts • joined 16 Jun 2009
My current contract has scheduled tasks and processes that still run under the user account of a guy who died two years ago at the start of the pandemic. His user account has gradually and very carefully had privileges removed so it's basically a service account now it can't be deactivated because nobody really knows how many important things run under that user account.
I am reminded of GNU Terry Pratchett.
I spent some time at a well known retail client a few years ago and we got a similarly unplanned lunch break when one of the service desk guys wrote a small script to change user passwords using powershell. As he was not a developer he completely bypassed user input sanitisation and error handling and basically strung the get-aduser commandlet (which gets user objects) and the set-aduser commandlet (which changes attributes, for example the password) together with a variable instead of a pipe.
At some time before lunch he ran his script and, as it was taking a bit of time to run, scuttled off to lunch. Over his hour lunch break those of us who ate at our desks started getting the 'windows needs your current credentials' message pop up on our computers inviting us to lock and unlock our desktops.
What had transpired, it seems, is that he had fallen victim to a classic faux pas - the get-aduser commandlet will assume, if you do not specify a filter, that you want every user object. "get-aduser jsmith" will return the object matching that name whereas "get-aduser" on its own will return an object containing every user object in the director (unless the command is scoped in another way). Fortunately for our hero he had scoped the command to an OU that was UK head office only and didn't extend to international users, store users, or more importantly the service accounts upon which the business ran. Around 3000 people had their passwords reset and it took quite a while to fix the issue. As everyone had their password set the same they couldn't just tell people that the password was "ChangeMe123" because that meant that anyone could access any account. The passwords had to all be reset again to something unique to the user (DoB and NI number I recall) so that it could be communicated widely. There was then the 2 day password retention rule that prevented anyone changing their password for a couple of days afterwards.
Companies should either hire people directly (fixed term or permie contracts) or use contractors that are proper contractors and treat them as such (not disguised employees/umbrella/inside IR35). If you are a contractor you provide a service and don’t have a manager or go to team meetings or have your hours and location of work dictated to you. Fixed term and perm get the benefits. If companies hire a contractor and then treat them like an employee they should be liable for the tax and benefits of an employee.
"Former UK trade minister and current Conservative MP Dr. Liam Fox"
I think you'll find that his actual title is "The disgraced former defence secretary, Dr Liam Fox" - it's a well worn title with a proud history of Tory defence secretaries who have been disgraced.
Surely if gov.uk have declared this person an employee then there are large amounts of holiday pay and other benefits, not to mention a hefty redundancy payment.
Can't have it both ways - or employees might soon find that they too are being taxed as an employee but treated like a contractor.
At a place I worked as a contractor there was a low level server ops guy, let's call him John Smith, and he wrote a very simple script to change passwords. I don't quite know how his script was more efficient that the one line of powershell that it ran but then he was a very low level person, the type who tend to do the stuff that nobody can be bothered to script because they can't script clicking on the next box.
So the script that "John" wrote basically took a username and changed the password. I would hazard a guess that it basically did:
Get-ADUser $user | Set-ADAccountPassword -NewPassword "Changeme123!"
OK, so there were some other options in there as well but you get the gist.
Anyway, "John' runs this script using his privileged account (let's him do desktop stuff like change passwords) and it seems to hang. He goes off to lunch.
At this point it's worth noting that in the line of powershell above if $user is null then Get-ADUser will get every user object in the domain and pipe all of them to the password change applet. It hadn't hung, it was just a little busy.
While "John" was off at lunch the rest of the IT department realised that they were unable to reach stuff, many had locked their desktops while eating their own supermarket "own brand" sandwiches at their desk and when they tried to unlock their desktops found that their passwords were no longer valid.
Later in the incident room it became apparent that "John" was responsible however he not only managed to retain his job but eventually managed to move sideways (and slightly down) into the desktop team.
Particularly domain names and hosting stuff - I spend a good few months in an old job (2007 - sub prime mortgage lender) identifying all the various domain names owned by present and former sales or IT directors and getting them transferred into one company account. The main company website nearly went because the domain was registered as a personal registration to the original sales director when the company started up and had never been transferred - he left nearly a year before my work started.
Given the short block periods a false positive isn't that much of a problem and you don't even need to block the game from the start. Just wait for the game to start and watch for spikes in streaming content then advertise a route to null0 into your network. Drop the route after 90 mins and wait for the next game.
It is more effective to drop traffic during the match than before because if you do it before the punters have time to find an alternative - watching it legally becomes a lot more attractive when you have missed the end of a few games.
The significance here is the fact it is IP rather than host name blocking - it's a blunter tool but harder to circumvent because you can use an alternate DNS provider but you can't use a different routing table.
DST (and indeed timezones) are not a change to the time, just a change to the way that the time is displayed; for the reason you mentioned and many more. The US and many other places change their DST on differing dates and many places don't do it at all.
Time is expressed in UTC, which is essentially very similar to Greenwich Mean Time. Daylight saving in the UK (BST; British Summer Time) is simply a display of UTC+1 so the systems comparing time clocks would still store and compare UTC to UTC. The difference with a leap second is that it is actually a change to UTC.
When "the clocks change" normally it is just the function of displaying the clock rather than the internal clock that changes except in these very rare and specific cases.
DST (and indeed timezones) are not a change to the time, just a change to the way that the time is displayed; for the reason you mentioned and many more. The US and many other places change their DST on differing dates and many places don't do it at all.
Time is expressed in UTC, which is essentially very similar to Greenwich Mean Time. Daylight saving in the UK (BST; British Summer Time) is simply a display of UTC+1 so the systems comparing time clocks would still store and compare UTC to UTC. The difference with a leap second is that it is actually a change to UTC.
All you folks talking about 800 a day rates are dreaming - you can pick up Windows support chimps really cheaply so you don't have to pay more than £150 for one. You don't even need to pay VAT as they don't earn enough to be VAT registered. No matter how good you think you are there is a paper MCSE who will undercut you.
The Register - Independent news and views for the tech community. Part of Situation Publishing
Biting the hand that feeds IT © 1998–2022
