Adding Kerberos to a router is overkill in my opinion. I'd agree on adding LDAP(s) auth support via sssd of course, but Kerberos is simply a bit beyond the scope.

But I really like your attitude and thanks four that first time PR!

Thank you for taking a look on the PR.

To be honest I don't think, that there is a clean way to do sssd-ipa without kerberos. Everything in a FreeIPA domain is kerberos authenticated. The module could also be extended to be used for an active directory domain, which is also kerberos authenticated. I see your point that kerberos for a regular router is out of scope, but in my current understanding VyOS is not just a regular router, as it can also function as a very sophisticated VPN gateway, container host or Reverse-/Web-Proxy. All of which are also features not available on regular routers.

Is this a topic worth a discussion or is your stand on this taken?

As I understabd FreeIPA is an alternative to ActiveDirectory? And SSSD should support authentication via LDAP only if the backend is AD.

That would add support for authentication via AD, FreeIPA and OpenLDAP with one single implementation which would be preferred.

Lets wait for the other maintainers what their idea/thoughts are.

Until the other maintainers share their ideas and thoughts I would like to add some context about FreeIPA and Active Directory, as I have the impression, that the difference between FreeIPA and Active Dirctory is not completely clear.

FreeIPA and Active Directory are somewhat comparable and serve, to some point, a comparable need, but are in fact completety differnet solutions.
FreeIPA and Active Directory are not compatible to each other. The project that aims for Active Directory compatibilty would be Samba AD Controller. It is correct, that FreeIPA as well as AD are using LDAP Directories as their primary point to hold their data. But one has to note, that the schemas used by FreeIPA and Active Directory are very different. FreeIPA is a solution to manage Identites, Policies and Audit. The main purpose of FreeIPA is to serve POSIX compatible systems. Active Directory servers Microsoft Windows Systems with Identity and Policy, Group Policies and what not . FreeIPA is able to form a trusted relationship between AD Domains, which enables users of Active Directory Domains to authenticate on resources managed by an IPA domain. It is also important to notice that we are talking about a highly integrated domain system consisting of LDAP, PKI, DNS and Kerberos, not "only" an LDAP directory. It is true, that basic user and group information can be gatherd by regular LDAP binds and service accounts. But there are many more possibilities with using sssd-ipa. For example you can have a host based access control via LDAP stored PAM definitions, where it is possible to centrally define which user or group can access which systems via which PAM services, you can have the native 2FA TOTP or HTOP function of FreeIPA, the list goes on. Those entries can, in my understanding, only be viewed by correctly authenticated entities in the domain.
The only way to correctly authenticate to an FreeIPA and a trusted Active Directory is by utilizing Kerberos.
SSSD provides different modules (sssd-ad and sssd-ipa) to deal with the different requirements and schemas of AD and FreeIPA. sssd-ipa is also the only way to have the trust feature between FreeIPA and AD wroking, as sssd is communicating with the Active Direcotry itself and not via the FreeIPA LDAP directory.

I can recommend the official Red Hat documentation as FreeIPA is the upstream project to Red Hat IDM, if one want's to dive deeper into to architecture and system.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/planning_identity_management/overview-of-planning-for-identity-management-and-access-control-planning-identity-management

Edit: Changed sentence about Samba and Active Directory Equivalent

PR https://github.com/vyos/vyos-1x/pull/2157 closed due to long standing conflicting files.

LDAP would be a nice improvement but adding Kerberos in 2024 is not the proper way to go. Feel free to re-submit/discuss this