Ability to authenticate with Kanidm to Samba (epic)

[Firstyear]

This is an epic describing the required parts for Kanidm and Samba to integrate to allow samba to authenticate shares against Kanidm.

There are a huge number of outstanding questions, design elements, tests, and ground work to perform before this can be completed.

Samba internally has to model a large number of windows design choices which necessitates a number of components to integrate and bridge the worlds.

• A method to map a Kanidm user to a SID
• A method to map SID's back to Kanidm users, and then to gid/uid numbers
• The ability to authenticate to the shares

Each of these has many layers and considerations. For example, samba allows authentication to shares with ntlm or kerberos, but ntlm is "on the way out" per microsofts efforts. This necessitates kerberos ( #1614 ). There are also environments where we would have a mac or windows machine attempting to connect to a samba server that is managed by kanidm, which may require IA-KERB if line of sight to the kanidm server isn't possible, but also requires the ability to initialise a ccache on a non-configured Kanidm machine. This has huge implications for how we manage credentials, and may even need PKINIT or something else. Kerberos traps us into passwords so we have to think how to make this secure in some manner. We have to consider Linux machines where a user SSHes to a machine with an ssh key and never presents any passwords at all meaning we need domain joining and other mechanisms to determine chains of authentication trust ( #2626, #2495 ). We need to ensure that whatever we create is secure. And finally as a project we must be able to test every part and conform with our project policy ( https://github.com/kanidm/kanidm/blob/master/book/src/developers/faq.md#is-the-project-going-to-create-a-microservice-like-architecture )

And ultimately, we can not allow kerberos' design flaws and limitations to impact Kanidm making correct choices. Our goal isn't to morph Kanidm to AD, but to determine if it's possible to emulate what is needed without sacrificing Kanidm's identity.

Initially to proceed we must investigate and determine what is or is not possible. This will assist in the creation of a design.

Research tasks currently should include:

• Behaviour of MacOS and Windows to a Samba Server with a KDC offering authentication types such as PKINIT or password, and if these can be satisfied.
  • Behaviour if the KDC is not visible with line of sight (IA-KERB) and if Samba supports this.
  • If there are other ways we can perform the auth request withou a password/PKINIT, or if client support packages will be required.
  • If Samba works with all of this and the KDC only offers MS-KKDCP.
  • Documentation of all this and the requirements especially around DNS
• Processes to initialise a credentials cache manually from constructed data on a client machine so that direct AS-REQ isn't required and out-of-band ccache can be initialised (important for bypassing krb auth limitations on linux)
• What is required for Samba ID mapping to be viable.

And probably more. It would be good when these research tasks are undertaken that they are documented to allow other members of the community to reproduce them for further development.

[Firstyear]

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/b4af186e-b2ff-43f9-b18e-eedb366abf13

[TheRealGramdalf]

Thought I'd add my thoughts here, since I actually have a semi-functional version in use.

The following is an excerpt from my NixOS configuration that is running as an LXC on Proxmox. Said LXC is configured to:

• Use kanidm-unixd to consume POSIX accounts from Kanidm
• (unrelated to auth, added for completeness) Advertise SMB shares via samba-wsdd and avahi
• Find user info for samba via PAM
• Require some security features (smb encrypt = required, access only from the local network (no port forwarding), minimum protocol SMB3)

{ config, lib, pkgs, ... }: {
  config = {
    services = {
      # Consume POSIX accounts from Kanidm
      kanidm = {
        enablePam = true;
        clientSettings.uri = "https://auth.domain.tld";
      };
      
      # Network shares
      samba = {
        package = pkgs.samba4Full;
        # ^^ Needed to enable mDNS support
        # See https://github.com/NixOS/nixpkgs/blob/592047fc9e4f7b74a4dc85d1b9f5243dfe4899e3/pkgs/top-level/all-packages.nix#L27268
        enable = true;
        openFirewall = true;
        shares = {
          media = {
            path = "/tank/media";
            writable = true;
            comment = "Crab Rave";
          };
        };
        extraConfig = ''
          ## Security Settings
          # Permissions
          inherit owner = unix only 
          inherit permissions = yes 
          # ^^ Overrides `create` and `force create` `mask/mode`
          # Authentication
          passdb backend = tdbsam:/tank/samba-passdb.tdb 
          security = user 
          hosts allow = 192.168.1. 127.0.0.1
          hosts deny = ALL
          guest account = nobody 
          map to guest = Bad User
          # Generic
          server smb encrypt = required
          # ^^ Note: Breaks `smbclient -L <ip> -U%`
          server min protocol = SMB3_00
        '';
      };
      avahi = {
        publish.enable = true;
        publish.userServices = true;
        # ^^ Needed for samba to automatically register mDNS records
        nssmdns4 = true;
        enable = true;
        openFirewall = true;
        allowInterfaces = [ "upstream0" ];
      };
      samba-wsdd = {
        enable = true;
        openFirewall = true;
        interface = "upstream0";
        hostname = "aer-files";
      };
    };
  };
}

In regards to how this actually functions, SMB uses PAM to find user information (UID:GID), which is served by kanidm-unixd. It should be noted that the user does not need to be able to log in; SMB only needs to be able to query UID:GID information (which can be performed on any posix account, regardless of the pam_allowed_login_groups).
For passwords, SMB currently keeps an LXC-local TDBSAM database (passdb backend = tdbsam:/tank/samba-passdb.tdb ), so a password must be set for a user (i.e. using smbpasswd -a a-kanidm-user) before SMB will authenticate them. If the user presents a UID:GID upon login, SMB ignores it in favour of whatever it comes to after the login flow. If it is a user that doesn't exist in the SMB password database, or the password is incorrect, it throws an incorrect login` error.

The last thing I can think of to note is that a relatively simple solution to fix the password database being decoupled from Kanidm might be to create a semi-editable LDAP directory which contains the necessary info such that SMB can check passwords against that instead - I believe you can set the passdbbackend separately from the security mode, meaning that UID:GID perms can come from kanidm-unixd, and passwords can come directly from ldap or ldaps.

This seems like the simplest way to get a functional system, especially since it should be entirely transparent to the client - as long as it supports SMB3 (which any self respecting client should post wannacry), it should function without any modifications necessary.

I realize that there are considerations in terms of what defaults Kanidm wants to support (e.g. passwords with SMB), as well as the desire to not become active directory - but this might at the very least be an interim measure in lieu of a more sophisticated system that doesn't require kanidm-unixd. Just thought I'd share my setup since it seemed relevant.

[Firstyear]

I have a pretty similar setup tbh. Kanidm unixd for uid/gidnumbers and a tdb for the passwords. We discussed this with @scabrero as a possibility but the issue is MS wants to kill of NTLM so the days are numbered for this kind of setup.