Good that you make it work.

AFAIK in Active Directory is very rarely used anonymous bind, so you should
always use the username/password configuration in your properties files.
Or properly setup the anonymous bind, because according to logs there
are some ldap attributes with strange values.

The aaa-ldap doesn't use the user from the login fields, as it's not correct.
You should have setup some search user which does authorization, it
should not be performed by user which is trying to login.

On Tue, Dec 13, 2016 at 9:35 PM, Bill Bill <jax2568@outlook.com> wrote:

I was actually able to resolve this by renaming the corresponding files in the /etc/pki/ovirt-engine/aaa directory and the extentions.d directory. Then, I simply ran the ovirt-engine-extension-aaa-ldap-setup command and re-added the AD back. The users were not affected since they were already in oVirt.

 

I have found that in the properties file, it stores the login information I used to set the connection up. If I remove those, the error is generated. It seems as though unless there’s a username/password stored in plain text in that file, the AD connection will not work. Is this correct or are there some variables that can be entered to use the info from the login fields?

 

From: Martin Perina
Sent: Tuesday, December 13, 2016 3:28 AM
To: Bill Bill
Cc: users@ovirt.org; Ondra Machacek
Subject: Re: [ovirt-users] unexpected comma found at the end of DN string

 

Hi,

could you please execute following command to get full logs from login flow and share those logs?

  ovirt-engine-extensions-tool --log-level=FINEST aaa login-user --profile=<PROFILE_NAME> --user-name=<USERNAME>

Please replace <PROFILE_NAME> and <USERNAME> according to your setup.

Thanks

Martin Perina


On Tue, Dec 13, 2016 at 9:03 AM, Bill Bill <jax2568@outlook.com> wrote:

Hello,

 

Getting this and have no idea where to begin:

 

server_error: Unexpected comma or semicolon found at the end of the DN string.

 

Server is set up with AD for authentication. The problem started after attempting to change SSL certificates with our own however, that failed so we rolled back. Now, authentication doesn’t work anymore and the error is vague.


_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.phx.ovirt.org/mailman/listinfo/users



_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.phx.ovirt.org/mailman/listinfo/users