2019-05-17 06:57:26 -05:00
|
|
|
package ldap
|
|
|
|
|
|
|
|
import (
|
2021-09-14 03:49:37 -05:00
|
|
|
"fmt"
|
2019-05-17 06:57:26 -05:00
|
|
|
"testing"
|
|
|
|
|
2023-02-28 05:13:46 -06:00
|
|
|
"github.com/go-ldap/ldap/v3"
|
2021-09-14 03:49:37 -05:00
|
|
|
"github.com/stretchr/testify/assert"
|
2019-05-17 06:57:26 -05:00
|
|
|
)
|
|
|
|
|
2021-09-14 03:49:37 -05:00
|
|
|
func TestIsMemberOf(t *testing.T) {
|
|
|
|
tests := []struct {
|
|
|
|
memberOf []string
|
|
|
|
group string
|
|
|
|
expected bool
|
|
|
|
}{
|
|
|
|
{memberOf: []string{}, group: "*", expected: true},
|
|
|
|
{memberOf: []string{"one", "Two", "three"}, group: "two", expected: true},
|
|
|
|
{memberOf: []string{"one", "Two", "three"}, group: "twos", expected: false},
|
|
|
|
}
|
|
|
|
|
|
|
|
for _, tc := range tests {
|
|
|
|
t.Run(fmt.Sprintf("isMemberOf(%v, \"%s\") = %v", tc.memberOf, tc.group, tc.expected), func(t *testing.T) {
|
2022-04-22 08:45:54 -05:00
|
|
|
assert.Equal(t, tc.expected, IsMemberOf(tc.memberOf, tc.group))
|
2019-06-13 09:47:52 -05:00
|
|
|
})
|
2021-09-14 03:49:37 -05:00
|
|
|
}
|
|
|
|
}
|
2019-06-13 09:47:52 -05:00
|
|
|
|
2021-09-14 03:49:37 -05:00
|
|
|
func TestGetUsersIteration(t *testing.T) {
|
|
|
|
const pageSize = UsersMaxRequest
|
|
|
|
iterations := map[int]int{
|
|
|
|
0: 0,
|
|
|
|
400: 1,
|
|
|
|
600: 2,
|
|
|
|
1500: 3,
|
|
|
|
}
|
2019-06-13 09:47:52 -05:00
|
|
|
|
2021-09-14 03:49:37 -05:00
|
|
|
for userCount, expectedIterations := range iterations {
|
|
|
|
t.Run(fmt.Sprintf("getUserIteration iterates %d times for %d users", expectedIterations, userCount), func(t *testing.T) {
|
|
|
|
logins := make([]string, userCount)
|
2019-06-13 09:47:52 -05:00
|
|
|
|
LDAP: Divide the requests (#17885)
* LDAP: Divide the requests
Active Directory does indeed have a limitation with 1000 results
per search (default of course).
However, that limitation can be workaround with the pagination search feature,
meaning `pagination` number is how many times LDAP compatible server will be
requested by the client with specified amount of users (like 1000). That feature
already embeded with LDAP compatible client (including our `go-ldap`).
But slapd server has by default stricter settings. First, limitation is not 1000
but 500, second, pagination workaround presumably (information about it a bit
scarce and I still not sure on some of the details from my own testing)
cannot be workaround with pagination feature.
See
https://www.openldap.org/doc/admin24/limits.html
https://serverfault.com/questions/328671/paging-using-ldapsearch
hashicorp/vault#4162 - not sure why they were hitting the limit in
the first place, since `go-ldap` doesn't have one by default.
But, given all that, for me `ldapsearch` command with same request
as with `go-ldap` still returns more then 500 results, it can even return
as much as 10500 items (probably more).
So either there is some differences with implementation of the LDAP search
between `go-ldap` module and `ldapsearch` or I am missing a step :/.
In the wild (see serverfault link), apparently, people still hitting that
limitation even with `ldapsearch`, so it still seems to be an issue.
But, nevertheless, I'm still confused by this incoherence.
To workaround it, I divide the request by no more then
500 items per search
2019-07-03 09:39:54 -05:00
|
|
|
i := 0
|
2021-09-14 03:49:37 -05:00
|
|
|
_ = getUsersIteration(logins, func(first int, last int) error {
|
|
|
|
assert.Equal(t, pageSize*i, first)
|
LDAP: Divide the requests (#17885)
* LDAP: Divide the requests
Active Directory does indeed have a limitation with 1000 results
per search (default of course).
However, that limitation can be workaround with the pagination search feature,
meaning `pagination` number is how many times LDAP compatible server will be
requested by the client with specified amount of users (like 1000). That feature
already embeded with LDAP compatible client (including our `go-ldap`).
But slapd server has by default stricter settings. First, limitation is not 1000
but 500, second, pagination workaround presumably (information about it a bit
scarce and I still not sure on some of the details from my own testing)
cannot be workaround with pagination feature.
See
https://www.openldap.org/doc/admin24/limits.html
https://serverfault.com/questions/328671/paging-using-ldapsearch
hashicorp/vault#4162 - not sure why they were hitting the limit in
the first place, since `go-ldap` doesn't have one by default.
But, given all that, for me `ldapsearch` command with same request
as with `go-ldap` still returns more then 500 results, it can even return
as much as 10500 items (probably more).
So either there is some differences with implementation of the LDAP search
between `go-ldap` module and `ldapsearch` or I am missing a step :/.
In the wild (see serverfault link), apparently, people still hitting that
limitation even with `ldapsearch`, so it still seems to be an issue.
But, nevertheless, I'm still confused by this incoherence.
To workaround it, I divide the request by no more then
500 items per search
2019-07-03 09:39:54 -05:00
|
|
|
|
2021-09-14 03:49:37 -05:00
|
|
|
expectedLast := pageSize*i + pageSize
|
|
|
|
if expectedLast > userCount {
|
|
|
|
expectedLast = userCount
|
LDAP: Divide the requests (#17885)
* LDAP: Divide the requests
Active Directory does indeed have a limitation with 1000 results
per search (default of course).
However, that limitation can be workaround with the pagination search feature,
meaning `pagination` number is how many times LDAP compatible server will be
requested by the client with specified amount of users (like 1000). That feature
already embeded with LDAP compatible client (including our `go-ldap`).
But slapd server has by default stricter settings. First, limitation is not 1000
but 500, second, pagination workaround presumably (information about it a bit
scarce and I still not sure on some of the details from my own testing)
cannot be workaround with pagination feature.
See
https://www.openldap.org/doc/admin24/limits.html
https://serverfault.com/questions/328671/paging-using-ldapsearch
hashicorp/vault#4162 - not sure why they were hitting the limit in
the first place, since `go-ldap` doesn't have one by default.
But, given all that, for me `ldapsearch` command with same request
as with `go-ldap` still returns more then 500 results, it can even return
as much as 10500 items (probably more).
So either there is some differences with implementation of the LDAP search
between `go-ldap` module and `ldapsearch` or I am missing a step :/.
In the wild (see serverfault link), apparently, people still hitting that
limitation even with `ldapsearch`, so it still seems to be an issue.
But, nevertheless, I'm still confused by this incoherence.
To workaround it, I divide the request by no more then
500 items per search
2019-07-03 09:39:54 -05:00
|
|
|
}
|
|
|
|
|
2021-09-14 03:49:37 -05:00
|
|
|
assert.Equal(t, expectedLast, last)
|
LDAP: Divide the requests (#17885)
* LDAP: Divide the requests
Active Directory does indeed have a limitation with 1000 results
per search (default of course).
However, that limitation can be workaround with the pagination search feature,
meaning `pagination` number is how many times LDAP compatible server will be
requested by the client with specified amount of users (like 1000). That feature
already embeded with LDAP compatible client (including our `go-ldap`).
But slapd server has by default stricter settings. First, limitation is not 1000
but 500, second, pagination workaround presumably (information about it a bit
scarce and I still not sure on some of the details from my own testing)
cannot be workaround with pagination feature.
See
https://www.openldap.org/doc/admin24/limits.html
https://serverfault.com/questions/328671/paging-using-ldapsearch
hashicorp/vault#4162 - not sure why they were hitting the limit in
the first place, since `go-ldap` doesn't have one by default.
But, given all that, for me `ldapsearch` command with same request
as with `go-ldap` still returns more then 500 results, it can even return
as much as 10500 items (probably more).
So either there is some differences with implementation of the LDAP search
between `go-ldap` module and `ldapsearch` or I am missing a step :/.
In the wild (see serverfault link), apparently, people still hitting that
limitation even with `ldapsearch`, so it still seems to be an issue.
But, nevertheless, I'm still confused by this incoherence.
To workaround it, I divide the request by no more then
500 items per search
2019-07-03 09:39:54 -05:00
|
|
|
|
|
|
|
i++
|
|
|
|
return nil
|
|
|
|
})
|
|
|
|
|
2021-09-14 03:49:37 -05:00
|
|
|
assert.Equal(t, expectedIterations, i)
|
LDAP: Divide the requests (#17885)
* LDAP: Divide the requests
Active Directory does indeed have a limitation with 1000 results
per search (default of course).
However, that limitation can be workaround with the pagination search feature,
meaning `pagination` number is how many times LDAP compatible server will be
requested by the client with specified amount of users (like 1000). That feature
already embeded with LDAP compatible client (including our `go-ldap`).
But slapd server has by default stricter settings. First, limitation is not 1000
but 500, second, pagination workaround presumably (information about it a bit
scarce and I still not sure on some of the details from my own testing)
cannot be workaround with pagination feature.
See
https://www.openldap.org/doc/admin24/limits.html
https://serverfault.com/questions/328671/paging-using-ldapsearch
hashicorp/vault#4162 - not sure why they were hitting the limit in
the first place, since `go-ldap` doesn't have one by default.
But, given all that, for me `ldapsearch` command with same request
as with `go-ldap` still returns more then 500 results, it can even return
as much as 10500 items (probably more).
So either there is some differences with implementation of the LDAP search
between `go-ldap` module and `ldapsearch` or I am missing a step :/.
In the wild (see serverfault link), apparently, people still hitting that
limitation even with `ldapsearch`, so it still seems to be an issue.
But, nevertheless, I'm still confused by this incoherence.
To workaround it, I divide the request by no more then
500 items per search
2019-07-03 09:39:54 -05:00
|
|
|
})
|
2021-09-14 03:49:37 -05:00
|
|
|
}
|
|
|
|
}
|
LDAP: Divide the requests (#17885)
* LDAP: Divide the requests
Active Directory does indeed have a limitation with 1000 results
per search (default of course).
However, that limitation can be workaround with the pagination search feature,
meaning `pagination` number is how many times LDAP compatible server will be
requested by the client with specified amount of users (like 1000). That feature
already embeded with LDAP compatible client (including our `go-ldap`).
But slapd server has by default stricter settings. First, limitation is not 1000
but 500, second, pagination workaround presumably (information about it a bit
scarce and I still not sure on some of the details from my own testing)
cannot be workaround with pagination feature.
See
https://www.openldap.org/doc/admin24/limits.html
https://serverfault.com/questions/328671/paging-using-ldapsearch
hashicorp/vault#4162 - not sure why they were hitting the limit in
the first place, since `go-ldap` doesn't have one by default.
But, given all that, for me `ldapsearch` command with same request
as with `go-ldap` still returns more then 500 results, it can even return
as much as 10500 items (probably more).
So either there is some differences with implementation of the LDAP search
between `go-ldap` module and `ldapsearch` or I am missing a step :/.
In the wild (see serverfault link), apparently, people still hitting that
limitation even with `ldapsearch`, so it still seems to be an issue.
But, nevertheless, I'm still confused by this incoherence.
To workaround it, I divide the request by no more then
500 items per search
2019-07-03 09:39:54 -05:00
|
|
|
|
2021-09-14 03:49:37 -05:00
|
|
|
func TestGetAttribute(t *testing.T) {
|
|
|
|
t.Run("DN", func(t *testing.T) {
|
|
|
|
entry := &ldap.Entry{
|
|
|
|
DN: "test",
|
|
|
|
}
|
LDAP: Divide the requests (#17885)
* LDAP: Divide the requests
Active Directory does indeed have a limitation with 1000 results
per search (default of course).
However, that limitation can be workaround with the pagination search feature,
meaning `pagination` number is how many times LDAP compatible server will be
requested by the client with specified amount of users (like 1000). That feature
already embeded with LDAP compatible client (including our `go-ldap`).
But slapd server has by default stricter settings. First, limitation is not 1000
but 500, second, pagination workaround presumably (information about it a bit
scarce and I still not sure on some of the details from my own testing)
cannot be workaround with pagination feature.
See
https://www.openldap.org/doc/admin24/limits.html
https://serverfault.com/questions/328671/paging-using-ldapsearch
hashicorp/vault#4162 - not sure why they were hitting the limit in
the first place, since `go-ldap` doesn't have one by default.
But, given all that, for me `ldapsearch` command with same request
as with `go-ldap` still returns more then 500 results, it can even return
as much as 10500 items (probably more).
So either there is some differences with implementation of the LDAP search
between `go-ldap` module and `ldapsearch` or I am missing a step :/.
In the wild (see serverfault link), apparently, people still hitting that
limitation even with `ldapsearch`, so it still seems to be an issue.
But, nevertheless, I'm still confused by this incoherence.
To workaround it, I divide the request by no more then
500 items per search
2019-07-03 09:39:54 -05:00
|
|
|
|
2021-09-14 03:49:37 -05:00
|
|
|
result := getAttribute("dn", entry)
|
|
|
|
assert.Equal(t, "test", result)
|
LDAP: Divide the requests (#17885)
* LDAP: Divide the requests
Active Directory does indeed have a limitation with 1000 results
per search (default of course).
However, that limitation can be workaround with the pagination search feature,
meaning `pagination` number is how many times LDAP compatible server will be
requested by the client with specified amount of users (like 1000). That feature
already embeded with LDAP compatible client (including our `go-ldap`).
But slapd server has by default stricter settings. First, limitation is not 1000
but 500, second, pagination workaround presumably (information about it a bit
scarce and I still not sure on some of the details from my own testing)
cannot be workaround with pagination feature.
See
https://www.openldap.org/doc/admin24/limits.html
https://serverfault.com/questions/328671/paging-using-ldapsearch
hashicorp/vault#4162 - not sure why they were hitting the limit in
the first place, since `go-ldap` doesn't have one by default.
But, given all that, for me `ldapsearch` command with same request
as with `go-ldap` still returns more then 500 results, it can even return
as much as 10500 items (probably more).
So either there is some differences with implementation of the LDAP search
between `go-ldap` module and `ldapsearch` or I am missing a step :/.
In the wild (see serverfault link), apparently, people still hitting that
limitation even with `ldapsearch`, so it still seems to be an issue.
But, nevertheless, I'm still confused by this incoherence.
To workaround it, I divide the request by no more then
500 items per search
2019-07-03 09:39:54 -05:00
|
|
|
})
|
|
|
|
|
2021-09-14 03:49:37 -05:00
|
|
|
t.Run("username", func(t *testing.T) {
|
|
|
|
value := "roelgerrits"
|
|
|
|
entry := &ldap.Entry{
|
|
|
|
Attributes: []*ldap.EntryAttribute{
|
|
|
|
{
|
|
|
|
Name: "username", Values: []string{value},
|
2019-05-17 06:57:26 -05:00
|
|
|
},
|
2021-09-14 03:49:37 -05:00
|
|
|
},
|
|
|
|
}
|
2019-05-17 06:57:26 -05:00
|
|
|
|
2021-09-14 03:49:37 -05:00
|
|
|
result := getAttribute("username", entry)
|
|
|
|
assert.Equal(t, value, result)
|
|
|
|
})
|
2019-05-17 06:57:26 -05:00
|
|
|
|
2022-11-22 06:47:53 -06:00
|
|
|
t.Run("letter case mismatch", func(t *testing.T) {
|
|
|
|
value := "roelgerrits"
|
|
|
|
entry := &ldap.Entry{
|
|
|
|
Attributes: []*ldap.EntryAttribute{
|
|
|
|
{
|
|
|
|
Name: "sAMAccountName", Values: []string{value},
|
|
|
|
},
|
|
|
|
},
|
|
|
|
}
|
|
|
|
|
|
|
|
result := getAttribute("samaccountname", entry)
|
|
|
|
assert.Equal(t, value, result)
|
|
|
|
})
|
|
|
|
|
2021-09-14 03:49:37 -05:00
|
|
|
t.Run("no result", func(t *testing.T) {
|
|
|
|
value := []string{"roelgerrits"}
|
|
|
|
entry := &ldap.Entry{
|
|
|
|
Attributes: []*ldap.EntryAttribute{
|
|
|
|
{
|
|
|
|
Name: "killa", Values: value,
|
2019-05-17 06:57:26 -05:00
|
|
|
},
|
2021-09-14 03:49:37 -05:00
|
|
|
},
|
|
|
|
}
|
2019-05-17 06:57:26 -05:00
|
|
|
|
2021-09-14 03:49:37 -05:00
|
|
|
result := getAttribute("username", entry)
|
|
|
|
assert.Empty(t, result)
|
2019-05-17 06:57:26 -05:00
|
|
|
})
|
2021-09-14 03:49:37 -05:00
|
|
|
}
|
2019-05-17 06:57:26 -05:00
|
|
|
|
2021-09-14 03:49:37 -05:00
|
|
|
func TestGetArrayAttribute(t *testing.T) {
|
|
|
|
t.Run("DN", func(t *testing.T) {
|
|
|
|
entry := &ldap.Entry{
|
|
|
|
DN: "test",
|
|
|
|
}
|
2019-07-24 04:49:18 -05:00
|
|
|
|
2021-09-14 03:49:37 -05:00
|
|
|
result := getArrayAttribute("dn", entry)
|
2019-07-24 04:49:18 -05:00
|
|
|
|
2021-09-14 03:49:37 -05:00
|
|
|
assert.EqualValues(t, []string{"test"}, result)
|
|
|
|
})
|
2019-07-24 04:49:18 -05:00
|
|
|
|
2021-09-14 03:49:37 -05:00
|
|
|
t.Run("username", func(t *testing.T) {
|
|
|
|
value := []string{"roelgerrits"}
|
|
|
|
entry := &ldap.Entry{
|
|
|
|
Attributes: []*ldap.EntryAttribute{
|
|
|
|
{
|
|
|
|
Name: "username", Values: value,
|
2019-05-17 06:57:26 -05:00
|
|
|
},
|
2021-09-14 03:49:37 -05:00
|
|
|
},
|
|
|
|
}
|
2019-06-13 09:47:52 -05:00
|
|
|
|
2021-09-14 03:49:37 -05:00
|
|
|
result := getArrayAttribute("username", entry)
|
2019-06-13 09:47:52 -05:00
|
|
|
|
2021-09-14 03:49:37 -05:00
|
|
|
assert.EqualValues(t, value, result)
|
|
|
|
})
|
2019-05-17 06:57:26 -05:00
|
|
|
|
2022-11-22 06:47:53 -06:00
|
|
|
t.Run("letter case mismatch", func(t *testing.T) {
|
|
|
|
value := []string{"CN=Administrators,CN=Builtin,DC=grafana,DC=org"}
|
|
|
|
entry := &ldap.Entry{
|
|
|
|
Attributes: []*ldap.EntryAttribute{
|
|
|
|
{
|
|
|
|
Name: "memberOf", Values: value,
|
|
|
|
},
|
|
|
|
},
|
|
|
|
}
|
|
|
|
|
|
|
|
result := getArrayAttribute("memberof", entry)
|
|
|
|
|
|
|
|
assert.EqualValues(t, value, result)
|
|
|
|
})
|
|
|
|
|
2021-09-14 03:49:37 -05:00
|
|
|
t.Run("no result", func(t *testing.T) {
|
|
|
|
value := []string{"roelgerrits"}
|
|
|
|
entry := &ldap.Entry{
|
|
|
|
Attributes: []*ldap.EntryAttribute{
|
|
|
|
{
|
|
|
|
Name: "username", Values: value,
|
2019-05-17 06:57:26 -05:00
|
|
|
},
|
2021-09-14 03:49:37 -05:00
|
|
|
},
|
|
|
|
}
|
2019-05-17 06:57:26 -05:00
|
|
|
|
2021-09-14 03:49:37 -05:00
|
|
|
result := getArrayAttribute("something", entry)
|
2019-06-13 09:47:52 -05:00
|
|
|
|
2021-09-14 03:49:37 -05:00
|
|
|
assert.Empty(t, result)
|
2019-05-17 06:57:26 -05:00
|
|
|
})
|
|
|
|
}
|