Possible Opportunity for Dental Office

[Velvis]

Only if you want to sink the ship.

That monster is MSSQL based, and you do NOT change the foundational identity from under an active MSSQL installation. That is, unless you want to murder it and have to find yourself more work.

The doctor being "cloud adverse" also means "security adverse" and he will get nuked, and he will try to sue you. That's your signal to run I'm afraid. There is no such thing as secure, on-premises technology that's still capable of accessing the Internet.

If he is going to continue to use a non-cloud-based version of Eaglesoft why is using on-prem Windows server not secure?

 

[Sky-Knight]

If he is going to continue to use a non-cloud-based version of Eaglesoft why is using on-prem Windows server not secure?

Single factor authentication everywhere.
Zero telemetry and monitoring.
Endpoint management dependent on a protocol that has a zero day every other week (SMB) or worse, no endpoint management at all.
Given no AD, Windows accounts are likely shared, and more than even odds they're admins too.
More than likely has RDP open to the entire LAN.
More than likely has crap passwords on admin accounts.
More than likely has a version of MSSQL running that is no supported, and not patched.
More than likely has crap passwords on SQL level authentication.

In short, the environment isn't managed, at all and it was never deployed correctly even with this operational context.

All of this means, as soon as anyone in that office clicks on the wrong thing, the entire operation goes up in smoke and in the process, exposes PHI.

This is how you get sued! The best case scenario for you is when it he gets hit, and he will get hit, you simply lose a customer because he's out of business. Either way, you need to replace the customer for your own operational integrity.

If you want to fix it, and there is no AD, then make sure that server is on its own VLAN, a hardware firewall only allows HTTPs from the LAN to that server, there's a real SSL certificate on that service, the platform is patched, the platform is running a supported and patched version of SQL, and the platform has something like Datto protecting it. Oh, and it needs to have the most recent version of Eaglesoft on it too. You will be tempted to punch RDP pinholes, DO NOT GIVE IN to this temptation. Open and close firewall rules on the local hardware firewall as required to enable management access, and make sure that firewall has an MFA protected admin login.

Or... because it's probably easier to read, the Copilot rewrite of above.

Snapshot of a Severely Mismanaged Environment

• Authentication: Single-factor authentication across the board—no MFA anywhere.
• Visibility: No telemetry, no monitoring. You're flying blind.
• Endpoint Management: Either nonexistent or reliant on SMB, a protocol plagued by frequent zero-days.
• User Accounts: No Active Directory means Windows accounts are likely shared—and odds are, they’re local admins.
• Remote Access: RDP is probably open to the entire LAN.
• Credentials: Admin accounts likely use weak passwords.
• Database: MSSQL is probably outdated, unsupported, and unpatched.
• SQL Auth: Expect weak or default credentials at the SQL authentication level.

What This Means
This environment is not just poorly managed—it was never properly deployed to begin with. One wrong click by any user, and the entire operation could be compromised, exposing Protected Health Information (PHI) in the process.

This is how lawsuits happen.
Best-case scenario: the client gets breached, goes out of business, and you lose them. Worst-case: you're implicated in a PHI exposure and face legal and reputational fallout. Either way, your operational integrity takes a hit.

If You’re Going to Fix It (Without AD)
Here’s the minimum viable remediation plan:

• Network Segmentation: Isolate the server on its own VLAN.
• Firewall Rules: Use a hardware firewall to restrict LAN traffic to HTTPS only. No RDP pinholes—ever. (Temporary access, then disable the rule)
• SSL: Install a valid SSL certificate on the hosted service.
• Platform Patching: Ensure the OS and application stack are fully patched.
• SQL Server: Run a supported and patched version of MSSQL.
• Backup & DR: Use a robust solution like Datto for backup and disaster recovery.
• Application Patching: Ensure the latest version of Eaglesoft is installed.
• Secure Admin Access: Use firewall rule toggling for remote management, and protect firewall admin access with MFA.

This isn’t just about best practices—it’s about survival. If you're supporting this kind of environment, you're sitting on a powder keg. Fix it before it blows.

 

[Velvis]

Single factor authentication everywhere.
Zero telemetry and monitoring.
Endpoint management dependent on a protocol that has a zero day every other week (SMB) or worse, no endpoint management at all.
Given no AD, Windows accounts are likely shared, and more than even odds they're admins too.
More than likely has RDP open to the entire LAN.
More than likely has crap passwords on admin accounts.
More than likely has a version of MSSQL running that is no supported, and not patched.
More than likely has crap passwords on SQL level authentication.

In short, the environment isn't managed, at all and it was never deployed correctly even with this operational context.

All of this means, as soon as anyone in that office clicks on the wrong thing, the entire operation goes up in smoke and in the process, exposes PHI.

This is how you get sued! The best case scenario for you is when it he gets hit, and he will get hit, you simply lose a customer because he's out of business. Either way, you need to replace the customer for your own operational integrity.

If you want to fix it, and there is no AD, then make sure that server is on its own VLAN, a hardware firewall only allows HTTPs from the LAN to that server, there's a real SSL certificate on that service, the platform is patched, the platform is running a supported and patched version of SQL, and the platform has something like Datto protecting it. Oh, and it needs to have the most recent version of Eaglesoft on it too. You will be tempted to punch RDP pinholes, DO NOT GIVE IN to this temptation. Open and close firewall rules on the local hardware firewall as required to enable management access, and make sure that firewall has an MFA protected admin login.

Or... because it's probably easier to read, the Copilot rewrite of above.

Snapshot of a Severely Mismanaged Environment

• Authentication: Single-factor authentication across the board—no MFA anywhere.
• Visibility: No telemetry, no monitoring. You're flying blind.
• Endpoint Management: Either nonexistent or reliant on SMB, a protocol plagued by frequent zero-days.
• User Accounts: No Active Directory means Windows accounts are likely shared—and odds are, they’re local admins.
• Remote Access: RDP is probably open to the entire LAN.
• Credentials: Admin accounts likely use weak passwords.
• Database: MSSQL is probably outdated, unsupported, and unpatched.
• SQL Auth: Expect weak or default credentials at the SQL authentication level.

What This Means
This environment is not just poorly managed—it was never properly deployed to begin with. One wrong click by any user, and the entire operation could be compromised, exposing Protected Health Information (PHI) in the process.

This is how lawsuits happen.
Best-case scenario: the client gets breached, goes out of business, and you lose them. Worst-case: you're implicated in a PHI exposure and face legal and reputational fallout. Either way, your operational integrity takes a hit.

If You’re Going to Fix It (Without AD)
Here’s the minimum viable remediation plan:

• Network Segmentation: Isolate the server on its own VLAN.
• Firewall Rules: Use a hardware firewall to restrict LAN traffic to HTTPS only. No RDP pinholes—ever. (Temporary access, then disable the rule)
• SSL: Install a valid SSL certificate on the hosted service.
• Platform Patching: Ensure the OS and application stack are fully patched.
• SQL Server: Run a supported and patched version of MSSQL.
• Backup & DR: Use a robust solution like Datto for backup and disaster recovery.
• Application Patching: Ensure the latest version of Eaglesoft is installed.
• Secure Admin Access: Use firewall rule toggling for remote management, and protect firewall admin access with MFA.

This isn’t just about best practices—it’s about survival. If you're supporting this kind of environment, you're sitting on a powder keg. Fix it before it blows.

Understood, but these issues aren't because of on-prem Windows server AD vs. Azure Cloud AD right?
Couldn't all of those concerns be addressed with a strictly on-prem Windows Server solution?
And to be clear I am not looking to get into a disaster because the dentist wants to make no changes. At this point I am just interested in learning why if he doesn't want to be cloud based, why his on-prem couldnt become secure and be an alternative.

 

[Sky-Knight]

Understood, but these issues aren't because of on-prem Windows server AD vs. Azure Cloud AD right?
Couldn't all of those concerns be addressed with a strictly on-prem Windows Server solution?
And to be clear I am not looking to get into a disaster because the dentist wants to make no changes. At this point I am just interested in learning why if he doesn't want to be cloud based, why his on-prem couldnt become secure and be an alternative.

No they cannot. AD can never be fully secured as implemented, the domain controller must have SMB open to the rest of the LAN, and that's typically the service that gets compromised during a lateral spread event. If it's not SMB it's RDP, and I don't know too many environments that keep their servers fully isolated. I don't mean a VLAN for servers, I mean a VLAN PER SERVER. AD is by design meant for a walled garden security model, so once the threat is on your network it's by design defenseless!

You can secure the application, but you cannot secure AD!

Orgs that must have AD, need Defender for Identity rolled out, Microsoft Sentinel deployed to ingest that data, and they also need Defender for Cloud and it's Defender for Endpoint for Servers entitlement deployed to all on premises servers. Only then, with a live SOC staring at the platform 24/7 is AD tolerable in terms of operational risk. I doubt your customer is willing to make this investment. But if they are! WINNER!

You're better off staying with the non-AD server, running only the Eagleworks software, and do as I described... stick it on its own VLAN and only allow HTTPs to it. At least then you're constraining the risk of the server to a single IIS service exposure, which is realistically hardenable to make contact with the Internet at large. The endpoints can be workgroup machines, the users have logins to the Eaglesoft software only.

 

[Velvis]

Is there a cloud based version Patterson Eaglesoft? and if so, is there a smooth upgrade path from the on-prem server version?