u/ClearlyTheWorstTech
ClearlyTheWorstTech
ClearlyTheWorstTech
I dunno, I've been doing this stuff since I was a teen? As a result, I know enough to plan ahead for possible outages. So, I have things implemented that meet most issues that cause worry. Everything else that could go wrong? Not super concerning because I know well enough what I can do and what I can't. Worrying over everything will fade with time.
Heck, one of my clients who has a couple of users with admin credentials? I connected to their server after not being able to get on and fix something the previous day. The server admin password failed. Connected on the VPN and tried using mremoteng with a saved credential. Also, failed to sign in. Called up one of the two admin credential holders,
TWT: "Hey, I know (their boss) has been getting weird about security lately, did he make you change the admin password?"
I get an immediate response from C.
C: "No, I wouldn't do that without telling you."
TWT: I blinked a couple of times before saying in a cheerful and friendly tone, "Oh, well, thank you for that. I really appreciate it, but the password was changed. You guys got hacked."
C: "What?" whoosh missed what I said completely.
TWT: In a calm tone, "Oh yeah, I am changing credentials and locking everything down, now. Need to figure out what they got into."
C: Panic rising, "uuuuuuuhhhhhh what? What do we do? Hacked?! Oh no!"
TWT: "Hey, I am going to assess. Let (boss) know and that we're already working on it. I am running a couple of scans and will let you know what I find."
We mitigated the attack and only ended up with about $5k worth of work from the event. This was back when this style of attack was extremely rare. Pre-EDR/MDR systems. I begged them not to contact their insurance company, but one guy wouldn't let it go. All we had to do to fix the issues? Restore from a backup from the previous night. The $5k of work was spent with only about $600 going to restoration. The rest was spent on making the insurance company content.
ClearlyTheWorstTech
So, I'm sad because the internet has changed so much, but I used to read way more. I don't know who all in the community was stumbling all those years ago, but I can't thank the IT community enough for a resource that used to be 100% community-based. Stumbleupon was once my favorite way to find new articles, tools and resources for learning more about IT and technology. It required way more trust than I have to spare lately. A web browser extension that would take you to websites that fit your interested subject tags with a click. It made me learn so much more than I think I would have otherwise found on my own. It got me more interested in open source projects, it got me into understanding switching networks better, history of malware, tools for device cleanup, history of computers, scripting with batch and powershell, etc. At the time when I was using Stumbleupon it was between 2008-2014.
ClearlyTheWorstTech
/op/, get autoruns from sysinternals to review the applications that are starting automatically.
Most windows server service accounts use the same domain account name for running services across multiple servers.
If you see services running as a "built-in" account name, like administrator, sometimes this is because a previous admin didn't know how to configure a service to run as a service-level account or as system. You will need to manually update these settings from services.msc or using powershell. If applications are running as a user that doesn't have an active session (query session)? That probably means the application is running from Taskschd.msc. Many tutorials for iis setup and other windows server services recommended using an administrator account to run the service without recommending to not use the actual administrator account. There is not a really good way to move these services to another account besides rebuilding the same application beside the existing one, setting proper permissions, and then changing the DNS property to point to the new service (in the case of iis).
By "Individual users" do you mean users that are not in the IT staff? Also, what remediation? Usually there were reasons for these changes. If those individual users are not creating active sessions on the server, what harm are they causing? Previously, it was necessary to set higher permissions for specific user accounts on a server running an application with active files inside programdata and "program files". For some ridiculous reason, some developers recommended admin access instead of changing NTFS and Share permissions for these folders. Alternatively, they might have needed to remotely access the server with an rdp session to run an application on the server. Again, this administrator access was probably provided when a less knowledgeable admin thought only administrators group granted remote access. I used to see these configurations all the time on older systems (server 2003/2008). This could also have been configured because a previous admin did not understand group policy, group file permissions or how to implement either. If this was the case? Administrator group allowed everyone to access the folder shares with no changes to NTFS or share permissions.
ClearlyTheWorstTech
Op, how could you disrespect their heritage??
ClearlyTheWorstTech
Any computer running a variant of Linux or BSD is going to be more responsive than Windows 11. Especially if you haven't tweaked explorer history or folder discovery off.
ClearlyTheWorstTech
You shouldn't tell your cousin that the one way to get management to give all the workers a raise is to form a union. ;D
ClearlyTheWorstTech
I would bet money those x1 users are doing one of the following: never cleaning up animal/people hair and taking the laptop home, beating the shit out of the things, comparing them to MacBook air and iPad they just bought, or taking them on the road where they are in a bag 90% of the time and unable to update anything which results in an unstable system. If it's in an office? They probably just want anything other than "the company laptop" because they have no idea what they have.
ClearlyTheWorstTech
It's good practice, too. I think within the past year every major provider has put out notifications for the requirement. Also, it's very likely if your domain on 365 is configured for DMARC that is part of the block as well. Iirc you can't setup spf, dkim and dmarc while also expecting to send unsigned messages from only an spf record not getting scrutinized more than your fully-authenticated emails.
ClearlyTheWorstTech
My favorite co-workers were the ones that collaborated and actually did their jobs. Then, they ran from the dumpster fire right after I departed.
ClearlyTheWorstTech
Okay, I'm a little more confused now. RD Gateway is designed to manage and implement external connections to local equipment. In other words, a single IP address, a NAT address, servicing RDP connections based on user accounts to connect with local resources. If your situation is a flat network and you just want to RDP to resources then there is no sense or need to run RD Gateway. If you are trying to implement a zero trust environment with RD Gateway, you can 100% allow a client VPN connection to manage the NAT connection between networks. This can even be implemented on a single firewall network. Just configure the VPN to take your local intranet traffic and only authenticate users connecting from that network. Then, have it connect to your protected network segment.
ClearlyTheWorstTech
This might seem like a dumb question, but is your RD Gateway on a domain? Or are you using a standalone server with local accounts? To what end is the RD Gateway being implemented?
Iirc it's also no longer a good practice to run an Rd Gateway as the platform has not seen any development for security. It's better to just vpn and then use rdp. Safer and encrypted at all times.
ClearlyTheWorstTech
Why not just run the script with Task Scheduler next time and run as "NT Authority\SYSTEM" for the user?
ClearlyTheWorstTech
Well, if you really want to throw away your productivity as a technician and your entire department and the managed solution isn't working yet...
Begin by running
c:\Program Files\Common Files\Microsoft Shared\ClickToRun\OfficeClickToRun.exe scenario=install scenariosubtype=uninstall sourcetype=None productstoremove=O365ProPlusRetail culture=en-us platform=x64 displaylevel=false forceappshutdown=true
Then I would recommend you roll out a new xml config with m365 ODT. Use config.office.com to build a new file with Outlook (classic) disabled and slight wretch Outlook (new) is selected.
ClearlyTheWorstTech
Definitely firewall problem. Several fortigate and Cisco units I've worked on will have "any" configured, but still block ports for everything except icmp, icmpv6, http, https, and unencrypted smb. So, you can navigate to practically anything that you would normally communicate with for connectivity, but you can't use any port-specific applications. It's frustrating.
ClearlyTheWorstTech
I'm confused though. Roku lets you setup parental lock on which apps are accessible and you can set a pin to allow access to the app store and the other unapproved apps. Plus, you can limit the visible apps to just the ones you want to make visible.
ClearlyTheWorstTech
I addition to this. LLM won't turn re-usable code blocks into modules you can cut and paste out of the original script in 6 months to use in the new project.
ClearlyTheWorstTech
I see! Okay, I didn't want to assume. I prefer the rubber duck approach myself.
So, my guess is that the certificate is failing for another reason, possibly related to your azure proxy. Have you read through these articles already?
https://tech.nicolonsky.ch/radius-aad-joined-devices/ - - I know this uses docker and freeradius, but it has good notes for the windows side configuration and NPS. From my read of the article, this author does actually complete the setup you're aiming for. Additionally, NPAS services might be too rigid for this kind of implementation and freeradius server for windows does exist.
https://www.securew2.com/blog/how-to-set-up-a-microsoft-radius-server - - this article is for a cloud radius solution that could potentially fix your problems by placing your radius server on an Azure connected platform. I'm entirely unaffiliated with this group and work at an msp. I don't want to sell you anything that costs more money. The author states that Azure and NPAS does not natively complete the process of connecting the two services.
If it was not clear, I have not attempted the solution you are aiming for, but I have been in your shoes several times before where it seems like one little nudge is all it takes to have everything work. It's tiring and frustrating, but you might succeed where others failed. I wish you the best of luck. Let us know where you land on this.
ClearlyTheWorstTech
So, I entered into an MSP that was this way. I didn't get access to the documentation until 2 months after my start date. I was experienced enough to handle random issues and hungry enough to work without training. There's documentation, but none of it is organized or consistent. The hit by a bus excel documents all have passwords applied to them and no one has they key. The names of clients are both abbreviated and written out. There are client names on the master client invoice that don't belong to any clients because they changed their name.
There are 860 endpoint devices on the remote access portal. 200 haven't seen power in 6 months. There are 3 separate patch policies available through the management software and none of them are configured on any of the endpoint computers. They are all updating at the whim of customers and Microsoft. There are over 40 networks deployed by the MSP, there are logic maps created in visio, but there again is no consistency. Some have the whole network. Other visio docs have just an implemented addition for part of a building. A handful of Visio documents have everything on them, logic map, passwords, network subnet, details, but switches while named at these locations, don't have office information or endpoint patch labels. So, half of the connections go off into the wall and no one knows where they end.
One guy tells you to wait for him to get there when you were assigned to investigate a wifi problem at a client site. You looked at the access points and see that they're the kind that can connect to a management software from the manufacturer AND you were provided access to this system for one client. You ask the guy who told you to wait for him to allow access to the management. He never responds. 3 hours later he shows up. Does not show you how he is checking the network. You already made a rough map of the Mac addresses you could find in the building coming from the SSID tool on your phone. He has you go to each room and read the Mac address on the device to him. Turns out he was just doing an ip scan and connecting to each access point manually. After seeing this happen. You ask why he doesn't use the management. He grumbles about it not being secure. You come to realize that you can't access any network equipment setup by this guy. He also wants to physically be there before doing any work on the issue. 6 months have gone by and the other Employee has out-right denied access to information vital to complete tickets assigned by the company owner. The owner, getting fed up, provides access to the rest of the MSP software systems that you have been asking for since week 1. On-site guy was sitting on one of the best documentation tools for IT on the market for over a year, untouched. No information added. No integration. Just making the company pay for something he decided didn't need to be set up. You fix twice as many problems as the on-site guy. You learned 70% of the customer base and have even fixed the ticketing system that you were told did not work any more. You implement an update policy and carefully push it to one company at a time and review the process / damage. After half the client-base is enrolled and updating, on-site guy finds the policy, you explain it to him "we don't want anything auto!" he exclaims before removing the policy and claiming you are going to break the customer networks.
Another 6 months goes by fast with more and more client exposure. You implement best practices everywhere you can. Frequent issues begin evaporating. Clients stop contacting you weekly. You have taken on more responsibility. Your company owner actually gave you the highest raise he could while keeping you in-line with the other technicians at the company. He had you implement the new ticketing system after the on-site guy hadn't put any time towards it for 6 months. You have finally started documenting with the documentation software. You wrote 4 scripts that were deemed "helpful" for gathering information from the guy who didn't like any automation. Around 12 other scripts are used by you and the other techs daily. You still can't access the network equipment. On-site guy is still hoarding it. You see him maybe 2 times a week now. You only ask him questions as a last resort. Owner hires a new guy and asks you to start training him.
2 months later and on-site guy puts in his 2 weeks notice after having the job for 5+ years. He convinces the owner to let him work out his last 2 weeks and to "stay on" as an afterhours/weekend job. His new job tells him that his start date is 5 weeks later than he assumed. It takes him 3 months to produce one password list that's wildly incomplete for the number of clients and equipment deployed. He doesn't return his company tools or equipment. On-site guy has had all of his access cut after we received word he started his new job.
You and the other technicians spend the next two months changing passwords on every piece of equipment you can access. All of it gets documented. On-site guy's responsibilities get divided up. Owner asks you to step up into the director role because you've been writing policies since the beginning and the other techs have less experience or are out of state working remotely 100% of the time.
By now, it's 2 years and 4 months since I started. We still have a handful of devices we can't access. We're replacing equipment that has recurring fees for equipment that our customers can own and receive updates without fear of losing support. All except for one person in the company was willing to move to the new ticketing system and documenting software. We moved to a new remote management suite that fully integrates into those two systems. The younger techs are finally seeing the concepts I told them about 8 months ago manifesting in our daily process and changing how we can deliver products to our customers. We're also about 4x as secure as we were previously.
ClearlyTheWorstTech
I mean, who doesn't like filling gaps?
ClearlyTheWorstTech
I appreciate the information provided, I realize that some of my questions might sound dumb/uninformed, but I am asking to rule out specific issues. This may seem silly to ask, but your test device connecting to the Wi-Fi, is it domain-joined and in the same OU for Policy 1 while you are testing Policy 2?
I'll try to explain: by not changing your Connection Request Policy, you are forcing more severe rejections.
If your test unit meets the group constraints for Policy 1 and Policy 2, but it's missing the authentication requirements for Policy 1, then you will have an NPS failure by only having Policy 2 authentication requirements in place. Additionally, this means Policy 3 will not be tested either.
If you configure your test device for Policy 3, but leave it in a group for Policy 2, NPS follows the hierarchy. While it could test for Policy 2 and 3, it will test Policy 2 first and fail if it doesn't Authenticate. At this point it will not test Policy 3. This is likely why using the username/password constraint causes a success on your test unit and why it doesn't reach Policy 3 in the hierarchy.
Also, If rule 1 has 2 constraints, but one constraint is not met, no NPS log is made, the connection is rejected. If rule 1 has 1 constraint and it is not met, it passes the request to the next rule. Constraints that overlap cannot have the same Connection Request Policy.
It might be beneficial to separate your policy by another condition and another Connection Request Policy. Adding an SSID/vlan for testing purposes would allow you to keep the same hierarchy that is in-use without breaking the existing process in use by other employees. If you configure your policy that doesn't work to have a different subnet? That fixes the possibility of your test device meeting the wrong criteria before it reaches the policy you want to test. Don't forget to update the Network Access Policy to match the Connection Request Policy.
ClearlyTheWorstTech
So, I'm with erased321 here when it comes to the issue at hand. That address mismatch is going to cause issues.
If the NPS log is still not showing any log values, check a few things:
You added your Wi-Fi access points/switches (whichever is handling the authentication requests) to your NPS Radius client list, right?
Does your NPS configuration have the right order? You need to have allowed authentication requests on top.
Lastly, I am assuming based on the log posted; you're running Windows NPAS server, you have both the Connection Request policy and a Network Policy configured with your security group, certificate, and smart card Auth, but is your eap/peap auth condition in line with both what your network device manufacturer supports and your GPO Security policies?
ClearlyTheWorstTech
I've played some wod, pathfinder, dark heresy, and 5e. I've also been reading R. A. Salvatore since high school. Just haven't played a ttrpg in 6 years or so.
Last campaign was a changling/werewolf campaign in wod where I played as an Ananasi with crafting and trauma maxed out. I was essentially Jeff the spider from The Grim Adventures of Billy and Mandy. Complete with "Why won't you love me, Dad!?" issues towards our main NPC.
ClearlyTheWorstTech
Indeed. Authy desktop is gone
ClearlyTheWorstTech
Also, if your domain cert isn't working, why not just use let's encrypt?
Imagine running a flat vlan and not segregating your traffic to have different levels of web filtering by address segment on the meraki.