jmerriweather / exldap Goto Github PK

Hello,

change_password/3 and change_password/4 directly edit the unicodePwd field of the user. It's an issue since this field might not be used depending on hte setup. For example, my setup uses the userPassword field and SSHA to hash the password.

Moreover, :eldap already provides a method_password method, why don't we use it ?

I would be glad to submit a patch.

Hello,

I recently updated to Erlang 24.3 on Unbuntu 21.10 and afterward Exldap.search_field/4 stopped working.

My erlang version:

erl -v

Erlang/OTP 24 [erts-12.3.1] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [jit]

Eshell V12.3.1 (abort with ^G)

Here the steps to reproduce the issue:

{:ok, connection} = Exldap.connect
{:ok, #PID<0.2141.0>}

settings = Application.get_env :exldap, :settings
base = settings |> Keyword.get(:base)

Exldap.search_field(connection, base, "objectCategory", "CN=Person,CN=Schema,CN=Configuration,DC=corp,DC=idm,DC=bz,DC=it")

The output is:

...
...
{:eldap_entry,
'CN=Name Surname,OU=USERS,OU=ViaMacello,OU=IDM,DC=corp,DC=idm,DC=bz,DC=it',
[...]},
{:eldap_entry,
'CN=Booking_Parking_Free_223,OU=ViaMacello,OU=IDM,DC=corp,DC=idm,DC=bz,DC=it',
...},
{:eldap_entry, ...},
{...},
...
], [], :asn1_NOVALUE}

Attempted function clauses (showing 1 out of 1):

    def from_record({:eldap_search_result, entries, referrals})

(exldap 0.6.3) lib/exldap_search_result.ex:23: Exldap.SearchResult.from_record/1
(exldap 0.6.3) lib/exldap.ex:554: Exldap.search/2

Thank you in advance
Steven

Thanks for making this.

I'm getting some unexpected behaviour with Exldap.verify_credentials/3.
When I pass an empty string as the password the response is :ok when I expected this to be {:error, :invalidCredentials}

Is this expected behaviour or a bug?

Valid user_dn and password work as expected:

{:ok, connection} = Exldap.open()
valid_user_dn = "CN=Elliott,OU=Users,DC=example,DC=com"
Exldap.verify_credentials(connection, valid_user_dn, "MyActualPassword")
=> :ok

Valid user_dn and incorrect password work as expected:

{:ok, connection} = Exldap.open()
valid_user_dn = "CN=Elliott,OU=Users,DC=example,DC=com"
Exldap.verify_credentials(connection, valid_user_dn, "IncorrectPassword")
=> {:error, :invalidCredentials}

Valid user_dn and incorrect empty string password return :ok

{:ok, connection} = Exldap.open()
valid_user_dn = "CN=Elliott,OU=Users,DC=example,DC=com"
Exldap.verify_credentials(connection, valid_user_dn, "")
=> :ok

Invalid user_dn and incorrect empty string password return :ok

{:ok, connection} = Exldap.open()
Exldap.verify_credentials(connection, "not_a_real_dn", "")
=> :ok

After upgrading to 0.6.1 I'm not able to connect to a server with ssl set to false.
It seems that is not valid to sent sslopts when ssl is set to false.

After changing

def open(server, port, ssl, timeout, sslopts) do
    :eldap.open([to_charlist(server)], [{:port, port}, {:ssl, ssl}, {:sslopts, sslopts}, {:timeout, timeout}])
end

to

def open(server, port, ssl, timeout, sslopts) do
    :eldap.open([to_charlist(server)], [{:port, port}, {:ssl, ssl}, {:timeout, timeout}])
end

the connection was successful.

In line 238 of exldap.ex settings could be nil and the subsequent Keyword.get could fail

A super quick & dirt workaround is to always set :exldap config in your app

config :exldap, settings: []

When the user dn and/or the password parameter passed to Exldap.verify_credentials contains an accent, the result is unexpected since it does return an error (invalid credentials) while it should not.

Any advice on how to overcome (and understand) this issue?

Thank you ;)

I need to change the dnAttributes atom to True with eldap. When I call the Extensible Match function with EXLdap I get an Error from eldap:

attrs = [{:matchingRule,"1.2.840.113556.1.4.1941"}, {:type,"member"}, {:dnAttributes, true}]
[matchingRule: "1.2.840.113556.1.4.1941", type: "member", dnAttributes: true]

** (throw) {:error, {:extensibleMatch_arg, {:dnAttributes, 'true'}}}
(eldap 1.2.8) eldap.erl:423: :eldap.mra/2
(eldap 1.2.8) eldap.erl:411: :eldap.extensibleMatch/2

This occurs whether I am using an Atom, binary, or char_list as the value for the :dnAttributes setting.

When I run the filter through eldap directly, I can get the filter back form eldap:
:eldap.extensibleMatch('CN=blaggo',[{:matchingRule,'1.2.840.113556.1.4.1941'}, {:type,'member'}, {:dnAttributes, :true}])

{:extensibleMatch,
{:MatchingRuleAssertion, '1.2.840.113556.1.4.1941', 'member', 'CN=blaggo',
'TRUE'}}

Obviously, this means I have a work around and can keep going, but it would be nice if the ExLDap extensibleMatch/2 function did not convert the value of the dnAttributes to a char_list (which is what I think the problem is) - Thanks.

Would be quite nice to be able to set a timeout on all functions that support it, especially connection/logging in/search.

Is it possible to verify the credentials of a ldap user using something other than the CN such as uid or samaccountname?

thank you

I've found that the functionality of OTP has changed in version 19, as a result ssl options do not appear to work.