mmitton/ldap

Basic LDAP v3 functionality for the GO programming language.

Basic LDAP v3 functionality for the GO programming language.

Install

For the latest version use:

go get gopkg.in/ldap.v2

Import the latest version with:

import "gopkg.in/ldap.v2"

Required Libraries:

• gopkg.in/asn1-ber.v1

Features:

• Connecting to LDAP server (non-TLS, TLS, STARTTLS)
• Binding to LDAP server
• Searching for entries
• Filter Compile / Decompile
• Paging Search Results
• Modify Requests / Responses
• Add Requests / Responses
• Delete Requests / Responses

Examples:

• search
• modify

Contributing:

Bug reports and pull requests are welcome!

Before submitting a pull request, please make sure tests and verification scripts pass:

make all

To set up a pre-push hook to run the tests and verify scripts before pushing:

ln -s ../../.githooks/pre-push .git/hooks/pre-push

---

The Go gopher was designed by Renee French. (http://reneefrench.blogspot.com/) The design is licensed under the Creative Commons 3.0 Attributions license. Read this article for more details: http://blog.golang.org/gopher

ldap's Issues

Invalid filter packets created for basic search

When I attempt a simple search as follows:

req := ldap.NewSearchRequest(
    "",
    ldap.ScopeBaseObject,
    ldap.DerefFindingBaseObj,
    0,                          // SizeLimit
    0,                          // TimeLimit
    false,                      // TypesOnly
    "(objectClass=*)",          // Filter
    []string{"rootDomainNamingContext"},
    nil,
)
res,err := conn.Search(req)

The server rejects the request. This is because the Go library is apparently generating invalid filter request packets, as detailed in this post on StackExchange: http://stackoverflow.com/q/27022146/13860

LDAP SASL bind (SCRAM SHA1) and dealing with binary/BER attribute values

The bind uses a distinguished name - is it possible to do a SASL bind using ID ([email protected]) instead ?
Also, is there a way to add/replace binary/BER attribute values. The API only allows strings.

"Message Result chan not found" on the 128th request

I have a strange error - I have a few hundred queries to run, each only differing in the basedn used. Every time I run the app, the 128th query fails with the same message:

Sending message 128
Receiving message 4294967168
Message Result chan not found (possible Abandon), MessageID: 4294967168

Every message before this succeeds, and I can confirm by seeing

MessageID: 127, ok: true
...
Sending message 127
Receiving message 127
...

I'm happy to send more information if needed, but does this give you any idea why the 128th query fails?

I want to set up a website and user can change ldap password on it

Could you realize it? thanks

SCRAM-SHA-1(-PLUS) + SCRAM-SHA-256(-PLUS) + SCRAM-SHA-512(-PLUS) + SCRAM-SHA3-512(-PLUS) supports

Dear @mmitton,

In first, I wish you a Happy New Year!

Can you add supports of :

• SCRAM-SHA-1
• SCRAM-SHA-1-PLUS
• SCRAM-SHA-256
• SCRAM-SHA-256-PLUS
• SCRAM-SHA-512
• SCRAM-SHA-512-PLUS
• SCRAM-SHA3-512
• SCRAM-SHA3-512-PLUS

"When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]".

• SCRAM-SHA-1(-PLUS):
  -- https://tools.ietf.org/html/rfc5802
  -- https://tools.ietf.org/html/rfc6120

• SCRAM-SHA-256(-PLUS):
  -- https://tools.ietf.org/html/rfc7677 since 2015-11-02
  -- https://tools.ietf.org/html/rfc8600 since 2019-06-21: https://mailarchive.ietf.org/arch/msg/ietf-announce/suJMmeMhuAOmGn_PJYgX5Vm8lNA

• SCRAM-SHA-512(-PLUS):
  -- https://tools.ietf.org/html/draft-melnikov-scram-sha-512

• SCRAM-SHA3-512(-PLUS):
  -- https://tools.ietf.org/html/draft-melnikov-scram-sha3-512

https://xmpp.org/extensions/inbox/hash-recommendations.html

-PLUS variants:

• RFC5056: On the Use of Channel Bindings to Secure Channels: https://tools.ietf.org/html/rfc5056
• RFC5929: Channel Bindings for TLS: https://tools.ietf.org/html/rfc5929
• Channel-Binding Types: https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml
• RFC 9266: Channel Bindings for TLS 1.3: https://tools.ietf.org/html/rfc9266

LDAP:

• RFC5803: Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted: Challenge Response Authentication Mechanism (SCRAM) Secrets: https://tools.ietf.org/html/rfc5803

HTTP:

• RFC7804: Salted Challenge Response HTTP Authentication Mechanism: https://tools.ietf.org/html/rfc7804

2FA:

• Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication: https://tools.ietf.org/html/draft-melnikov-scram-2fa

IANA:

• Simple Authentication and Security Layer (SASL) Mechanisms: https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml

Linked to:

• scram-sasl/info#1

go get fails for go1.2rc2

github.com/mmitton/asn1-ber

../../../Workspaces/go/src/github.com/mmitton/asn1-ber/ber.go:170: undefined: os.Error
../../../Workspaces/go/src/github.com/mmitton/asn1-ber/ber.go:183: undefined: os.Error
../../../Workspaces/go/src/github.com/mmitton/asn1-ber/ber.go:386: undefined: reflect.NewValue

conn.go's bug

conn.go at line 304 ,have many go routines is a bug.

it happens to a close channel to write

Search returns each result twice?

I seem to be getting each search result twice when querying Active Directory. Haven't dug into debugging yet. Any ideas?

I have some code like this:

  fmt.Printf("TestSearch: %s -> num of entries = %d\n", search_request.Filter, len(sr.Entries))
  for idx, entry := range sr.Entries {
    fmt.Printf("    %4d - entry: %+v\n", idx, entry)
  }

The output looks like this:

TestSearch: (objectClass=user) -> num of entries = 579
       0 - entry: &{DN:CN=Kanye West Attributes:[0xc2081b2420 0xc2081b2450]}
       1 - entry: &{DN:CN=Kanye West Attributes:[0xc2081b24b0 0xc2081b24e0]}
       2 - entry: &{DN:CN=Alicia Keys Attributes:[0xc2081b3140 0xc2081b3170]}
       3 - entry: &{DN:CN=Alicia Keys Attributes:[0xc2081b31d0 0xc2081b3200]}
...

panic: runtime error: send on closed channel

I'm building a web-application that uses an LDAP server for authentication.

All the server needs to do is login using the LDAP server, no authorizations are made beyond that.

When I use the library to login once, it works fine, however, on a second try, it will panic.

A very minimal example that reproduces this problem is:

package main

import (
    "fmt"
    "github.com/mmitton/ldap"
    "log"
)

const (
    ADDR   = "WWWW"
    DOMAIN = "XXXX"
    USER   = "YYYY"
    PASS   = "ZZZZ"
)

func main() {
    fmt.Println("Try 1...")
    doLDAP()

    fmt.Println("\nTry 2...")
    doLDAP()
}

func doLDAP() {
    conn, err := ldap.Dial("tcp", ADDR)
    if err != nil {
        log.Fatal(err)
    }
    defer conn.Close()

    fmt.Println("Connected successfully")

    err = conn.Bind(DOMAIN+"\\"+USER, PASS)
    if err != nil {
        log.Fatal(err)
    }

    fmt.Println("Logged in successfully")
}

Note that the constants are modified to working values for the LDAP server I am using.

The output is:

Try 1...
Connected successfully
Logged in successfully

Try 2...
closeAllChannels
panic: runtime error: send on closed channel

goroutine 25 [running]:
runtime.panic(0x5cd8e0, 0x71b19e)
    /tmp/go/src/pkg/runtime/panic.c:279 +0xf5
github.com/mmitton/ldap.func·003()
    /home/zeal/go/src/github.com/mmitton/ldap/conn.go:299 +0x4c
created by github.com/mmitton/ldap.(*Conn).sendProcessMessage
    /home/zeal/go/src/github.com/mmitton/ldap/conn.go:299 +0xa0