Authentication on the WEB interface by existing AD.

[Tom Elliott]

https://forums.fogproject.org/topic/11531/how-to-setup-microsoft-ad-ldap-for-fog-1-5-0

If you need more help ask, but this should be a good starting point.

While my screenshot looks different than what most see (1.5.9 vs 1.6 – which I’m running 1.6) the entry points should be the same. I also realize the version of what you’re seeing has a couple features that I am fairly sure does not exist in the 1.5.x series, but I wanted to give the whole screen shot so you have a working example.

[navarro]

@tom-elliott Thanks Tom for the quick response! I got to see this option but I thought it was to create a new LDAP instead of adding, sorry for my ignorance. I’m going to test it right now and I’ll tell you if it worked.

[navarro]

@tom-elliott Those were the settings, but it still doesn’t succeed. I could see that there is a second part in your image that doesn’t exist in my settings, could it be a different version of FOG?

[Tom Elliott]

@navarro You are only searching base? I’d suggest changing search scope to Subtree and below.

Yes, I already stated I was running a different version. So the majority of things are the same between your version and the one I run on.

So the besides the difference in appearance and adjustments from your environment to mine, this is pretty simple to work with.

There should be error logs.

Probably from /var/log/php-fpm/www-error.log?

I’m unsure of all the information, but I don’t know your environment. All I can do is show you a working example.

[Tom Elliott]

@navarro I would also suggest reviewing your “group search dn” field. Right now you seem to have it set to look for groups starting in forest:

interno.matera.com
  sti
    matera users

Or:

interno.matera.com
  matera users
    sti

I don’t exactly remember the order off the top of my head.

I would suggest removing the Group Search DN as that is basically saying it will be looking for Domain Admins and Domain Manager Computer Objects and Administrators from that OU. If they don’t exist there, then this would explain why it’s not working for you.

[navarro]

@tom-elliott Ok Tom, I will search for the logs, having news I will post here. Thanks

[navarro]

@tom-elliott Wow, I will test this

[navarro]

@tom-elliott

Tom, I went to / var / log / apache2 and opened the file with tail -f called error.log I got this error when trying to log into the fog interface:

"[Fri Mar 12 11: 43: 34.648641 2021] [proxy_fcgi: error] [pid 28399] [client 10.9.0.1:42280] AH01071: Got error 'PHP message: LDAP plugin :: _ result (). Search Method: search; Filter: (& (| (name = domain admins domain manager computer objects administrators)) (member = CN = Vinicius Navarro, OU = STI, OU = MATERA Users, DC = internal, DC = matera, DC = com)); Result : 0PHP message: LDAP plugin :: _ result (). Search Method: search; Filter: (& (| (name = users)) (member = CN = Vinicius Navarro, OU = STI, OU = MATERA Users, DC = internal, DC = matera, DC = com)); Result: 0PHP message: LDAP plugin :: authLDAP () Access level is still 0 or false. No access is allowed! ', Referer: http://10.9.15.181/fog/management /index.php "

Is it my user’s permission?

[Tom Elliott]

@navarro I don’t know if it’s user permission or not.

What I gather from the message:
It is not able to find any thing. Remember, it’s looking for the groups you’re attempting to match from within:

internal.matera.com
  MATERA Users
    STI

If the groups you’re looking for matching against are not in this OU, then it wouldn’t be able to find anything.

Of course, I’m also seeing a discrepency.

Your earlier posts show the dc as being from: interno.matera.com

I would suggest the following:

LDAP Connection Name: (Whatever you want to name it, just a name so nothing super important stored here)
LDAP Server Descripton: (You can leave it blank if you want)
LDAP Server Address: internal.matera.com (or interno.matera.com which ever is correct for your environment.)
LDAP Server Port: 389
Search Base DN: dc=internal,dc=matera,dc=com (or dc=interno,dc=matera,dc=com which ever is correct for your environment)
Group Search DN: Delete everything in this field. Unless you know the groups you need to match against are only in the OU, this is an added layer of complexity.
Admin Group: Domain Admins (NOTE: Your picture shows one Group named Domain Admins Domain Manager Computer Objects Administrators) This should be one single group, or if you’re going to be using multiples, seperate each group with a comma (e.g. Domain Admins,Domain Manager Computer Objects)
Mobile Group: Leave blank for now
Initial Template: Microsoft AD or leave as is if you want.
User Name Attribute: samaccountname
Group Member Attribute: member
Search Scope: Subtree and below (You can use base only but it will not recurse into any sub ou’s you may have. Subtree and below is usually the default.)
Bind DN: Should be the dn to a user who can read the AD. This isn’t needed in all environments, but certainly doesn’t hurt. This should be the attribute distinguishedName of the user.
Bind Password: Bind User’s password.

[navarro]

@tom-elliott

Very good, after understanding what you were trying to tell me and applying those changes I was able to finally understand what the problem was. It worked!

I thank you for your patience and perseverance in helping me! I just deployed the FOG in our organization, which by the way is working very well! About 400 machines in the park. Thank you Tom! The FOG is awesome!