Ask HN: I built a Yubikey-based domain controller. Is it sellable?
The individual discusses their R&D experience, highlighting a security appliance for remote access, targeting SMBs with varying IT budgets, and seeking marketing strategies amid challenges with legacy systems and client support.
The individual describes their experience in R&D, emphasizing the importance of maintaining customer relationships and intellectual property through on-premises solutions. In their small to medium-sized business (SMB), they continue to self-host various services for privacy and control but face challenges in providing remote access securely. To address this, they developed an appliance that protects internal web applications by implementing multiple layers of security, including a peer-to-peer VPN, mutual TLS, and OpenID Connect, all contained within a single unit similar to a domain controller.
The individual expresses a desire to market this appliance bundled with an admin panel but anticipates difficulties in reaching the appropriate market. They identify two primary client segments: those with significant IT budgets who require compatibility with legacy systems, which complicates the minimum viable product (MVP) development, and smaller clients with limited budgets who may need extensive support. The concern is that reliance on legacy systems could jeopardize their product's viability if major software providers, like Microsoft, decide to discontinue support for integrations. Conversely, smaller clients may not provide sufficient revenue in the short term, despite potential for growth. The individual seeks advice on how to effectively sell their product while navigating these challenges.
Related
34 commentsSo like it or not, you're going to be going door to door and helping smaller clients integrate this into their systems.
I think the right way to approach this would be to better understand the problems your clients would face when trying to integrate this kind of system, and then figure out how to solve them at scale in a way that you make customer acquisition and onboarding easier in the future.
Maybe it's things like creating base docker images for common services or OS pairings that have your stack already integrated. Maybe it's turnkey integrations with existing cloud identity providers or SSO. Maybe it's tailscale integration.
In fact tailscale is probably a good model to look at here - no large organization with an existing VPN solution is moving to tailscale, or at least weren't when they first started. But tailscale made a hard thing easy, and that's exactly what you're doing here.
What use case + benefit would folks have using this? Why should they trust you?
1. The market that needs this will not be capable to use it
2. The market that is capable to use it is also capable to use something like Cloudflare Access.
As for 'domain controller', like others have posted, that is a product or branded product from microsoft that doesn't have much to do with what you described. You could argue that Microsoft Windows Server can host most of those services, and will likely need a Microsoft Active Directory service (which in turn requires at least one Active Directory Domain Controller), it's not really related to what you are doing besides perhaps a user directory.
In a way, your product would address the classic setup that Microsoft (and Apple) have thrown away (many) years ago, companies are very bad at IT, and it gets worse as you focus on smaller companies and companies where IT is rather far removed from their core business. Something that is managed and maintained by someone else, that is where the money is, and in almost all cases that means the services and applications are not co-located in some office somewhere, mostly because the office is pretty much irrelevant these days.
From what I can tell you, good security is hard - we have prepared the product exactly as you describe on various levels (vpn, identity, SSO, Yubikey provisioning, etc) and prepared the architecture to be secure (multiple segments support: intranet, DMZ, proxy for exposing only public endpoints and functionalities publicly)…
What I observe in a year of the project being public and analysing heavily the landscape, similar projects, Reddit of what users are seeking and what problems they have is that: a lot of people and companies value comfort more then security (even if they will not admit it publicly), because security is hard. That also means there is w niche and need, but… it’s really hard to build a secure, easy to use and deploy security system…
Hope you don’t give up and peruse!, as it’s worth fighting about security and privacy
Unlike YubiKey they sell a wider range of products, such as secure hardware. It seems if you make it work with NitroKey they might be able to sell it as a bundle.
Probably won't hurt to reach out to them as a potential partner
It's interesting. You have built something tightly coupled ("like a classic domain controller") but then it is interacting with inspecific, totally decoupled stuff ("(p2p vpn), L4 (mTLS), and L7 (OIDC)").
"Tightly coupled for me, but not for thee" - why would someone who has adopted a decoupled application infrastructure decide that their domain controller should be coupled? I feel like people want one or the other in totality, they are either completely a Windows shop, or they are completely using bits and pieces of everything from everywhere. Everyone in between is ultimately migrating to one end or the other.
I can't speak for how to sell something I've never used. But I know Okta is very popular, and I encounter many IT people in many tech forums basically describe a feature of Okta. That's a huge scope. But that's a company that has tackled the dichotomy of coupled versus decoupled solutions, by simply providing everything. Is there a little bit of a chance that a single person can make something competitive with Okta? Yes!
Your target audience is likely companies running old-school, legacy Microsoft installations. These tend to be on-prem for the reasons you list.
The problem, though, is if these companies want a VPN, they already have it. You'll have to convince them that the VPN they've been using for decades is insecure (it's not).
----
Lastly, at a technical level, I'm not entirely sure what you achieve by requiring user/pass+yubikey on multiple layers of the stack. You don't gain any additional technical protection (since L3 would wrap everything else) while still having a single point of failure.
Even if it's the hardware authenticator your product currently works with.
Don't market it on current specifics; anyone not using a yubikey (personally or organisationally) will dismiss your product and never look at it again if you tie it to one specific third party vendor.
2. Linked to the above, this is not a competitor to Active Directory. It’s the antithesis. It’s not for a small office of PCs on desktops. It’s to properly secure IoT devices in different locations - sensors, telemetry that niche businesses sell - they sell the service that the device provides, and want a reliable small footprint security solution. Maybe you are it
Edit: I may have misunderstood the use case however - you mention zero trust but I may be missing how it validates at different layers - would love to know more however ! DM me if need be :-)
If you do this, make sure you support multiple hardware keys.
Single Yubikey and no backup is not safe, since the key can be lost or damaged easily.
Single Yubikey and SMS backup or "contact customer service to reset" backup is NOT secure, as it reduces your security to that of SMS or the CS rep.
Almost all of our software is in-house as we're very adept and efficient coders and it keeps the dependencies to a minimum, especially with regards to the licensing. We only have a single non-royalty free dependency and it's a total nightmare, the component is probably responsible for 30% of revenue but 95% of headaches.
So I'm trying to think of a hypothetical where we would buy such a product. Basically if I could have the same flexibility of making such software ourselves I would pay up to what we could expect it would cost to make it. If we were to need it it would be for a ~$1-3M USD project which we could carve off ~$100K for something like this due to the expected dev time savings which could be redirected to other areas while we scale up for the project. But for the second time round pony up bigger chunk say ~$200K to cover the cost of building it ourselves.
We were looking on standardizing on YubiKey, probably for the same reasons you went with them. Honestly I don't think my company should be your target market, we make software and are very good at it so it's a bit hard to sell us software, but if you decide to give out your contact details I'll make a note of it and keep an eye on what you choose to do.
Its not quite where you are now but smaller ISP's tend to have a list of bad options when it comes to user authentication. Do you want to support a large microsoft stack for AD and Radius? Do you want to manage one of the several terrible freely available radius implementations? Do you want to just let your billing system do it and hope that their proprietary code always works? Do you do something different thats completely vendor locked? The list goes on.
Meanwhile, small ISPs are a ridiculously soft target for cybercriminals. Most ISP's think they are invisible, and are exempt from hacking while the inverse is true and the inevitable outcome of that mentality results in heaps of customer data getting exposed.
It would take more market research than "Hey Hackernews" but an all in one appliance that secured userdata, applied stringent security to internal staff, authenticated wfh / field staff vpn logins via yubikey and let the ISP advertise optional secure links over their L2 connections would probably go down really well with small to medium ISP's that have only a few hundred customers, but get 80%+ of their revenue from high value business circuits.
What pain point are you trying to solve?
Your company must: * be quite large, including dedicated security teams * have a rock solid lengthy reputation (or you would need to be a big name in cybersecurity as its founder) * demonstrable security hygiene & certifications (secure development practices, pentesting, SOC2, etc.) * offer products with flexibility to suit my needs * solve a real problem I have, not a theoretical one
It's going to be an uphill challenge to build a company in the security market, unless you're a really big name in cyber. It's a worthwhile challenge, but expect it will take either big investment or a long time starting out before you see the rewards, especially with such a niche product that doesn't really fit into the large enterprise space, and given most small shops won't want the complexity or have the budget for it.
If not, then it's going to constrain businesses who want to open remote offices abroad. For example, having this appliance in a UK office while the US satellite office struggles to use it at latency, isn't a good experience.
Also you haven't mentioned backups. When the appliance eventually fails - which it will - how will a customer restore their data onto a replacement? And if they want to port their data out, how can they easily do this?
[1] https://learn.microsoft.com/en-us/windows-server/identity/ad... [2] https://learn.microsoft.com/en-us/entra/identity-platform/ms...
I think you should not have any issues integrating with legacy AD, but know bigger enterprises have mostly moved to online IdPs. Integrating with legacy AD will make your product also likely less secure. Maybe not the way to go?
- security product, startup, and platform companies
- political campaign offices
- certain law firms
- private military contractors
Most orgs depend on compliance to defray their net risk instead of going this hard to mitigate it. there are cases I'll leave for others, but what the above have in common is they are mission driven and operate outside the compliance narrative.
Go sell it, talk to potential buyers, see what works and what doesn’t, get feedback and adapt depending of that.
There is no point overthinking it especially if you already have a MVP. You will be wrong anyway.
How would you find some people who might be interested? This is the crux of marketing!
* find communities where such folks might hang out. This includes looking at places where self hosting is big (reddit, here, slacks, discords). Read stuff. If there's commercial channel, post there but respect the community.
* find in-person folks to talk to. local linux group meetups, local security meetups, etc.
* look up anyone on linkedin or in your work network and ask for 15 minutes of their time to get ideas on who might be interested in talking to you about this product. Stick to the 15 minutes, though.
* do some google searches that your potential customers might perform. From your description, I'm not sure I'd use the term "domain controller". Seems more like an app gateway or smart proxy instead. See who else is out there and who their customers are.
* searching might also turn up some communities for you to join.
* build a landing page explaining your product (as it will be). Add a mailing list. See if you can get anyone to sign up.
* You could buy some ads to drive folks to the landing page too. Use the same keywords you wanted to use. Set a limit as Google is happy to take your money.
* if you have more time than money, write up a few articles about building this, publish and share them. This sounds like a great topic for HN. Make sure you link to the landing page.
It's not easy, and this is why there are entire marketing and sales departments.
This post is a good overview too: https://www.kalzumeus.com/2013/04/24/marketing-for-people-wh...
Here's some classic patio11 wordplay.
> The other way I did, was I went home to Chicago, which is where my family is from, and took out $400 from an ATM, and walked around downtown Chicago and looked for salons and other massage therapists, that sort of thing.
> I walked in and said, “Hey, do you take walk‑ins?” “Yeah.” “Are you free right now?” “Yeah.” “Are you the business owner?” “Yeah.” “OK, I’ve got a weird proposition for you,” and no, not that kind of weird.
> “What’s the rate on a 30‑minute shoulder massage?” She would tell me. It’s almost always a she. I would say, “OK, I’m going to pay you the rate for a 30‑minute shoulder massage, but what I’m really interested in, I’m a small businessman, I live in Japan, I’m interested in the business of massage therapy. How about we just skip to that post‑massage cup of tea that you’re going to offer me,” I have learned this over the years. “Skip to the cup of tea, I’m going to pick your brains about how you run your business, and then I’ll go, no massage needed, and you get your money?” Almost everybody took me up on that, and nobody called the police. Yay.
Finding the right market is hard work and consists entirely of rejection until you find it and entirely of rejection if you don't.
> * Clients who have meaningful IT budgets...
> * Clients who are too small...
Selling is hard work and mostly or entirely rejection. Finding reasons not to sell is much easier and avoids the hard work and the psychological tolls of rejection.
> How would you sell what I've built?
One customer at a time. That's how selling is.
On a brighter note. Hardware is a useful abstraction. Customers with big budgets will pay handsomely for annual service contracts and you can fly out in business class, stay in a nice hotel and markup the cost 25% in the materials section of your time-and materials invoice.
Good luck.