mmitton/ldap

Basic LDAP v3 functionality for the GO programming language.

ldap's Issues

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

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.

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

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

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

Could you realize it? thanks

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

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]}
...

"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?

conn.go's bug

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

it happens to a close channel to write