GSSAPI support about ldap HOT 15 CLOSED

@johnweldon

https://sourcegraph.com/github.com/python-ldap/python-ldap/-/blob/Modules/LDAPObject.c#L797:13

It would be great if you cold take a look how to translate that into golang

Here is the actual openldap method in c

https://github.com/openldap/openldap/blob/master/libraries/libldap/sasl.c#L506

from ldap.

Ticket can be closed.

Keytab and other are supported now ;)
Ref: #449

Example usage:

package main

import (
	"fmt"
	"github.com/go-ldap/ldap/v3"
	"github.com/go-ldap/ldap/v3/gssapi"
	"log"
	"os"
)

type LdapConfig struct {
	Protocol      string
	Server        string
	Realm         string
	Basedn        string
	KrbKeytabPath string
	KrbConfPath   string
	Fqdn          string
}

func DefaultLdapConfig() LdapConfig {
	fqdn, err := os.Hostname()
	if err != nil {
		log.Fatal(err)
	}
	return LdapConfig{
		Protocol: "ldaps",
		Server:   "ldap.example.com",
		Realm:    "EXAMPLE.COM",

		// in my freeipa server it is:
		Basedn: "cn=users,cn=accounts,dc=example,dc=com",

		KrbKeytabPath: "/etc/krb5.keytab",
		KrbConfPath:   "/etc/krb5.conf",
		Fqdn:          fqdn,
	}
}

func main() {
	cfg := DefaultLdapConfig()

	// search this uid in ldap
	// in your case put different
	searchForUID := "patryk4815"

	client, err := gssapi.NewClientWithKeytab(
		"host/"+cfg.Fqdn,
		cfg.Realm,
		cfg.KrbKeytabPath,
		cfg.KrbConfPath,
	)
	if err != nil {
		log.Fatal("gssapi.NewClientWithKeytab", err)
	}
	defer client.Close()

	if err := client.Login(); err != nil {
		log.Fatal("client.Login", err)
	}

	conn, err := ldap.DialURL(fmt.Sprintf("%s://%s", cfg.Protocol, cfg.Server))
	if err != nil {
		log.Fatal("ldap.DialURL", err)
	}
	defer conn.Close()

	err = conn.GSSAPIBind(client, "ldap/"+cfg.Server, "")
	if err != nil {
		log.Fatal("conn.GSSAPIBind", err)
	}

	searchRequest := ldap.NewSearchRequest(
		cfg.Basedn,
		ldap.ScopeSingleLevel,
		ldap.NeverDerefAliases,
		1,
		0,
		false,
		fmt.Sprintf("(uid=%s)", ldap.EscapeFilter(searchForUID)),
		nil,
		nil,
	)

	searchResult, err := conn.Search(searchRequest)
	if err != nil {
		log.Fatal("conn.Search", err)
	}

	searchResult.PrettyPrint(2)
}

from ldap.

Do you have any thoughts about the task? Or a workaround?

from ldap.

I'm not familiar with using GSSAPI. If you're able to provide some more details on what an implementation might look like, it may increase the possibility of someone adding support.

from ldap.

Typically it requires building with cgo against c-bindings to a native library. I wouldn't expect it to be built into this library, but I'd consider an interface that allowed injecting a GSSAPI provider impl.

from ldap.

@vm86 describe, please, the integration of gssapi and ldap.

@liggitt Yes, I understand that you do not want to depend on cgo. In my opinion, the interface for implementing its authorization methods is the best option.

from ldap.

Hello, for the work of authorization it is necessary to implement the SASL
https://tools.ietf.org/html/rfc4513#section-5.2
after that this is RFC for GSSAPI ( kerberos )
https://tools.ietf.org/html/rfc4752

if necessary, I can write more details for GSSAPI. but first need a working SASL.

from ldap.

Correct, SASL needs to be implemented or linked in some fashion. There are a few Go libraries out there but I am unfamiliar with them and hesitate to recommend a specific one. The only deep, hands-on SASL+LDAP experience I have (dev-wise) would be via Perl's Net::LDAP suite coupled with Authen::SASL. I offer this as a comparative reference only ... maybe you'll find it helpful, maybe not ...

In addition to the SASL/GSSAPI (Kerberos5) mechanism, I recommend the SASL/EXTERNAL mechanism be implemented (possibly even first). This is used for PKI-based Mutual Auth against a DSA, just to name a practical use-case that is common in the world.

Simple Binds (a.k.a binding cleartext using a DN and password) are considered deprecated by just about every major directory service provider. This fact does not change whether or not one uses SSL/TLS (some believe it does, so I'm going to squash that myth here and now) 😄

It is true, Simple Bind support is necessary in many environments, but this should not be the only authentication choice in a nice library such as this.

Out of all modern SASL authentication mechanisms, at least in the LDAP world, SASL/EXTERNAL is the least painless to use and administer IMHO (having done it for years). I suspect that would be a far-less challenging SASL authentication mechanism to start implementing. There's far less to it than SASL/GSSAPI, both in the development sense and in the user-effort sense.

Lastly, and this is subjective I admit, but PKI Mutual Auth is a far smarter and more sustainable way to authenticate clients securely than Kerberos -- far, far fewer things are likely to go wrong with a PKI Issuance Chain than a Single Sign-On service.

from ldap.

https://github.com/apcera/gssapi might help? ⛽️ 🔥 😜

from ldap.

Feel free to propose an interface to expose for third party implementations

from ldap.

As I'm not-really-a-Go-programmer what does that mean?

from ldap.

@simmel - my suggestion wasn't directed at your proposal directly - just more generally. The big picture response is that to practically implement GSSAPI would probably mean using C bindings, which we're not willing to do now. If someone wants to build a third party library that wraps this one and adds GSSAPI, then we can discuss what interface/code changes are needed (if any) in this library to facilitate that.

from ldap.

Interesting @29x10 - I'll reopen this as an enhancement request and with a call for volunteer help.

from ldap.

I got the same problem, can't use Simple bind authentication

got error:
LDAP Result Code 8 "Strong Auth Required"

Found a third party library:
https://github.com/jcmturner/gokrb5

Maybe it will help?

from ldap.

I need this as well for enterprise use: I wrote a program to synchronize ldap-group members with local linux group users.
As sssd with krb5 is already used, I would not need a technical user to authorize with the active directory server, but could you the computer account to authorize?!

from ldap.