Another LDAP topic

[george1421]

@eazis The first thing that jumps out at me is the search based dn and group base dn. This should be the ladp path to find both the users and groups. So if you look for user jondoe it will look if that user exists in the TechnischeDienet OU. Same for the groups you provide the location to look for the group.

Now your admin group, should not be the ldap path but the name of the authorization group found in the group search dn path. So if your group in the Group Search DN is called fogadmins then you enter fogadmins in that admin group field

In the referenced link here is what that field instructions say

Admin Group - MANDATORY - (This is the name of the security/distribution group that admins need to be a part of in AD in order to login with LDAP) Note: Just the group name… not the whole CN as you already provided that information above.

For search group I would pick sub group and below, from personal experience. I wrote the original plugin for 1.5.0 that has been tweaked a few times since, but in general the flow is still the same. Lets try my recommendation and see where we end up.

[Eazis]

@george1421 So you say:

Search Base DN: DC=YYYY,DC=XXXX,DC=com
Group Search DN: DC=YYYY,DC=XXXX,DC=com
Admin Group: TechnischeDienst

Is this correct?

[george1421]

@eazis That will work, or you can be more specific with the search base DNs. With your current example it will search all of your domain for the defined user and group.

If you were using a default windows ad structure you might make the search bases as:

Search Base DN: CN=Users,DC=YYYY,DC=XXXX,DC=com
Group Search DN: CN=Groups,DC=YYYY,DC=XXXX,DC=com

If you are setting the search base to the root of your ldap structure you will want to change the search method to current directory and below (sorry I don’t remember the exact term), but it means the current search base path and all OUs below.

Now for the admin group, TechnischeDienst this needs to be the ad group name that FOG will try to find the user in. If the user is not in that group then access is denied to the fog server.
So the first part of the ldap plugin searches to see if the user account exists in the Search Base DN path. If the user is in that path, then it searches for the group defined in the Group Search DN path. If the group is found then it sees if the user exists in that group. At least that was the original flow.

So to answer your original question will what you have work, yes it should as long as if you change the search method to current OU and all sub ous and TechnischeDienst is the name of a windows group that contains the user you want to login.

[Eazis]

@george1421 I tried it with both settings but no luck…

[george1421]

@eazis Would you send another screen shot of the ldap config page, please.

From your iniital screen shot it look like you have groups and users in the same OU?

In your original post you made reference to TechnischeDienst, is that an AD group or OU?

If you put the AD browser in advanced mode. Then select the FOG admin group and go to properties, in the properties there should be an advanced menu or properties menu, this tab only exists when the AD browser is in advanced mode. Will you provide me the ldap path (from the DN field on the properties tab) for both the fog admin group and a test user that you want to log into FOG. Lets start with the full dn for both objects and work our way back into the field values.

[Eazis]

@george1421 sorry for my delay. Weekend between…

TechnischeDienst is a OU.
My AD browser is already in advanced mode. What you mean with the FOG admin group??

[astrugatch]

Can you go to Fog Configuration then to Fog Settings then Plugin: LDAP and screenshot what is there for LDAP ports and User Filter?

Also For “Admin Group”, that shouldn’t be the name of an OU but rather the name of a security group that your users are a member. That group should be located somewhere within the parameters set by the Group Search DN.

[Eazis]

@astrugatch

[astrugatch]

@eazis

Did you make the changes for your admin group setting to be a group rather than an OU as you have it?

[Eazis]

@astrugatch Yes, i tried this, but no result…

[Eazis]

Anyone who can help me with this?

[Tom Elliott]

@eazis Can you please get your error logs and present them as you attempt to login.

Unless I’m mistaken, LDAP is logged in the PHP error (php-fpm or apache.error depending on Redhat based vs Debian based respectively).

This can give us more information.

First, I want to say, the OU isn’t the same as a group. So as @astrugatch has stated, is the correct action.

Is your AD configured as SSL only connections? This could be part of the problem but I’m just grabbing at straws with this thought.

So I’m assuming YYYY.XXXX.com isn’t the real domain of your environment. That said, is whatever your server address actually accessible from the FOG server?

Normally Server address should be the IP address (or fqdn) of your AD/LDAP server.

IS port 389 indeed what you would want.

Also, I notice that “Use Group Matching (recommended)” is not checked. While I don’t know off the top of my head what this means, I’m pretty sure it is indeed recommended hence the verbiage we’ve added. Please see if checking this box gives you assistance.

Next, for troubleshooting reasons, I’d suggest starting simply.

Change your Admin Group to something like Users, and see if that works.

I also want to give some understanding of the Bind DN.

IF you are logging in with a user named Zabbix, that user must be able to read all environments to confirm the users. I’d almost suggest removing this and the Bind Password during initial stand up just to be on the testing side until we figure out what’s not working and why.

[Eazis]

@tom-elliott Many thanks!! I used now the internal ip address of the AD server … This was the whole problem.
A vaild domain name here did not work.

Normally this AD server is reachable with this fqdn YYYY.XXXX.com (it’s not the real domain). I can’t type public this domain here for security reasons.

I can now login with users from my AD into FOG.