Unsolved
This post is more than 5 years old
1 Rookie
•
37 Posts
1
14778
LDAP / FreeIPA / Red Hat Identity Manager integration
Sorry about the multi-post but I think I hit a length limit.
Whilst I can see there's lots of people trying to setup ldap auth to AD, (I'm aware the AD directory type works just fine for some colleagues of mine). There doesn't seem to be much in the way of setting this up with actual LDAP.
Links to people talking about Active Directory LDAP integration.
I don't have a working configuration, but hopefully this post will provide enough technical details that someone from the development team can replicate this issue.
Here is the settings I have (I've setup iDRACs to talk to FreeIPA / real LDAP so I'm pretty certain I know what I'm doing):
When I click the Test and enter valid credentials:
I get a successful response.
From there I click "Finish" then head to "Import Directory Users" (I see someone from Dell has said in one of the linked posts above this is incorrectly labelled and should be directory groups)
I then assign and import the group "ome_admins" as the "Administrator Role":
So far so good.
I logout as admin and then try to sign in user "dan" who is a member of that "ome_admins" group. I get the same invalid credentials that most of you are seeing.
It’s a standard setup of FreeIPA, version: 4.5.0.
Here's a dump of the relevant sections of ldap in standard ldif format:
user definition:
# dan, users, accounts, example.com dn: uid=dan,cn=users,cn=accounts,dc=example,dc=com displayName: Dan uid: dan krbCanonicalName: dan@EXAMPLE.COM objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry loginShell: /bin/sh initials: DD gecos: Dan sn: dan homeDirectory: /home/dan mail: dan@example.com krbPrincipalName: dan@EXAMPLE.COM givenName: Dan cn: Dan ipaUniqueID: e426343a-5100-11e8-9ef5-525400838a16 uidNumber: 658600001 gidNumber: 658600001 mepManagedEntry: cn=dan,cn=groups,cn=accounts,dc=example,dc=com memberOf: cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com memberOf: cn=ome_admins,cn=groups,cn=accounts,dc=example,dc=com krbLastPwdChange: 20180621202748Z krbPasswordExpiration: 20180919202748Z krbExtraData:: AAJECixba2FkbWluZEBFWEFNUExFLkNPTQA= krbLoginFailedCount: 0 krbLastFailedAuth: 20180621201212Z krbTicketFlags: 128 # dan, groups, compat, example.com dn: cn=dan,cn=groups,cn=compat,dc=example,dc=com objectClass: posixGroup objectClass: ipaOverrideTarget objectClass: top gidNumber: 658600001 ipaAnchorUUID:: OklQQTpleGFtcGxlLmNvbTplNDM2ZjFhOC01MTAwLTExZTgtOWVmNS01MjU0MD A4MzhhMTY= cn: dan # dan, groups, accounts, example.com dn: cn=dan,cn=groups,cn=accounts,dc=example,dc=com objectClass: posixgroup objectClass: ipaobject objectClass: mepManagedEntry objectClass: top cn: dan gidNumber: 658600001 description: User private group for dan mepManagedBy: uid=dan,cn=users,cn=accounts,dc=example,dc=com ipaUniqueID: e436f1a8-5100-11e8-9ef5-525400838a16
group definition:
# ome_admins, groups, compat, example.com dn: cn=ome_admins,cn=groups,cn=compat,dc=example,dc=com objectClass: posixGroup objectClass: ipaOverrideTarget objectClass: top gidNumber: 658600007 memberUid: dan ipaAnchorUUID:: OklQQTplGFtcGxlLmNvbTo0MzY0MWNiNi01MmY4LTExZTgtYjk5OC01MjU0MD A4MzhhMTY= cn: ome_admins # ome_admins, groups, accounts, example.com dn: cn=ome_admins,cn=groups,cn=accounts,dc=example,dc=com objectClass: top objectClass: groupofnames objectClass: nestedgroup objectClass: ipausergroup objectClass: ipaobject objectClass: posixgroup cn: ome_admins ipaUniqueID: 43641cb6-52f8-11e8-b998-525400838a16 gidNumber: 658600007 member: uid=dan,cn=users,cn=accounts,dc=example,dc=com
Here’s what the ldap server sees in it’s log /var/log/dirsrv/slapd-EXAMPLE-COM/access
[21/Jun/2018:21:24:56.407195824 +0100] conn=93 fd=92 slot=92 SSL connection from 10.0.1.44 to 10.0.1.42 [21/Jun/2018:21:24:56.458281739 +0100] conn=93 TLS1.2 256-bit AES-GCM [21/Jun/2018:21:24:56.458632790 +0100] conn=93 op=0 BIND dn="" method=128 version=3 [21/Jun/2018:21:24:56.458750327 +0100] conn=93 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="" [21/Jun/2018:21:24:56.459235207 +0100] conn=93 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(uid=dan)” attrs=ALL [21/Jun/2018:21:24:56.461249511 +0100] conn=93 op=1 RESULT err=0 tag=101 nentries=1 etime=0 [21/Jun/2018:21:24:56.461861790 +0100] conn=93 op=2 UNBIND [21/Jun/2018:21:24:56.461874847 +0100] conn=93 op=2 fd=92 closed - U1 [21/Jun/2018:21:24:56.463107772 +0100] conn=94 fd=119 slot=119 SSL connection from 10.0.1.44 to 10.0.1.42 [21/Jun/2018:21:24:56.507118699 +0100] conn=94 TLS1.2 256-bit AES-GCM [21/Jun/2018:21:24:56.507419073 +0100] conn=94 op=0 BIND dn="uid=dan,cn=users,cn=compat,dc=example,dc=com" method=128 version=3 [21/Jun/2018:21:24:56.508223185 +0100] conn=94 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=dan,cn=users,cn=accounts,dc=example,dc=com" [21/Jun/2018:21:24:56.508631107 +0100] conn=94 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(&(uid=dan))” attrs="cn" [21/Jun/2018:21:24:56.509144946 +0100] conn=94 op=1 RESULT err=0 tag=101 nentries=1 etime=0 [21/Jun/2018:21:24:56.509729979 +0100] conn=94 op=2 UNBIND
As you can see there’s an initial anonymous bind to look up my username “dan” requesting All attributes.
Then there’s a bind as my user using my full fn (pulled from the info in the previous search) which is also successful.
And then that’s the end of the log. Nothing more. Also no matter what settings I put into ldap server configuration pane for “Attribute of User Login”, “Attribute of Group Membership” or “Search Filter” none of them seem to be used. Even when I put “bob” (which is obviously wrong) the FreeIPA / LDAP server reports the same searches being performed as above.
I’m guessing it’s not passing these through correctly to the ldap client.
If you’ve made it this far congrats, thanks for staying with me. Hopefully this is enough information for someone at Dell to reproduce the issue.
DELL-Pupul M
1K Posts
0
August 7th, 2018 03:00
Hi,
Thanks for your detailed post. You should not be facing this problem in the upcoming release of OpenManage Enterprise. Please stay put.
dwatadventsol
1 Rookie
1 Rookie
•
37 Posts
0
September 19th, 2018 11:00
Hi Pupul,
Whilst this now almost works on a brand new IPA deploy which my test above used, servers that have been upgraded (such as our production ones) have a slightly different schema.
The member attribute is just the uid/login name rather than the full RDN of the user e.g.
rather than
Could we get a tick box added similar to that on the idrac that changes between using the uid/login and the full RDN of the user?
On a separate but related note: I upgraded from the tech release to 3.0.0 and the installed ca for LDAP remained in place but not matter what I put into the "Attribute of Group Membership" testing the settings tells me it's an invalid attribute. It does seem to accept it as I see the following in the LDAP server log, which of course fails due to the issue above.
When starting with a clean install rather than the upgrade, after uploading the CA certificate I get told it can't connect to the ldap server, logs on the server suggest the client has an issue with the ldap server certificate and closed the connection. Connecting without SSL seems to try to bind with the bindDn and and bindPassword that are prompted for (blank in my case as we allow anonymous binds FreeIPA default) which in turn results in the connection failing due to a failed bind.
More than happy to provide some more details / logs if you get someone to contact me.
DELL-Pupul M
1K Posts
0
September 26th, 2018 23:00
Hi,
Thanks for your reply and updating the post that it works. Currently, i don't think there is a way to do what you are asking for but i may me wrong. We will have to try this out on a local setup to confirm. I will get back to you.
dwatadventsol
1 Rookie
1 Rookie
•
37 Posts
0
January 2nd, 2019 23:00
Hi Pupul, I can confirm this is still very broken on 3.1.0 (Build 134). It's not even close to working.
I've configured it with a binddn and password, and eventually get a successful test. However when I go to add the external group when binding with the the bindDN and password used for the connection I see a search filter of:
(&(cn=[groupSEarchedFor])(uniqueMember=[BindDN]))
UniqueMember isn't a valid attribute in our ldap (it is in AD) and it should be "member" as specified on the connection details page as "Attribute of Group Membership", but even then this would only bring back groups that user is a member of.
Any attempts to use a different username and password result in a failed connection.
This really isn't that hard to get right and I can't believe that basic LDAP authentication is so broken and has been for 3 versions now. In my original post I covered how to set up a test environment for this, it takes less than 15 minutes!
Please get someone to contact me and I can walk them through it if that would be helpful.
NoOneOfConsequence
28 Posts
0
April 22nd, 2019 11:00
I stumbled across this thread while working on this, and I'm happy to report that I have managed to get an iDRAC 8 to authenticate against Red Hat IdM.
The key in my case was using the groups in the "compat" tree, which include the memberUid attribute, rather than the member attribute (which is the user's DN). This requires that the schema compatibility plugin be enabled on your IdM server(s); this is managed with the ipa-compat-manage command, and it appears to be enabled by default.
My settings are:
I have a single group defined in the iDRAC group settings. Its Group DN uses the compat tree: cn=...,cn=groups,cn=compat,dc=... (Note the ...,cn=groups,cn=compat,dc=..., rather than the normal ...,cn=groups,cn=accounts,dc=....)
Here is the redacted output from a settings test:
I hope that this will be helpful to someone.
dwatadventsol
1 Rookie
1 Rookie
•
37 Posts
0
April 22nd, 2019 12:00
Hi NoOneOfConsequence,
Thanks for your idrac configuration. It’s similar to the one I’m using on idrac6-9 and those covered on the idrac forum, however this thread is about hooking the OME appliance to FreeIPA which still doesn’t work.
The key is that the option of “Use Distinguished Name to Search Group Membership” doesn’t exist in the OME Enterprise Appliance and therefore the LDAP searches are incorrect.
Dan
NoOneOfConsequence
28 Posts
0
April 22nd, 2019 14:00
Oops!
Apologies for the off-topic post. This was quite literally the only seemingly relevant hit that Google turned up for "FreeIPA idrac."
In fact, even now knowing that there's an "idrac forum" out there somewhere, I'm still unable to find it. (Yes, @Anonymous, your community web site really is that terrible.)
dwatadventsol
1 Rookie
1 Rookie
•
37 Posts
0
July 9th, 2019 03:00
@DELL-Pupul M@DELL-Daniel MyAny news? Seems it's still broken under 3.2.
Putting anything in the Attribute of group membership fails without even attempting to query the LDAP/FreeIPA server.
Silver-mox
1 Rookie
1 Rookie
•
60 Posts
0
September 3rd, 2019 01:00
+1 here. running v3.2.1..
I'm having the same issue with FreeIPA, @DELL-Pupul M@DELL-Daniel My any updates?
thanks
lukasst
3 Posts
0
March 5th, 2020 01:00
Hi, any update?
3.3.1 (Build 12) freeipa ldap integration is still not working.
dwatadventsol
1 Rookie
1 Rookie
•
37 Posts
0
April 10th, 2020 06:00
I've done some digging.
I spotted this query in my FreeIPA dirserv logs, which is broken in 2 ways:
So we can work around this by adding entryUUID as another name for ipaUniqueID. Please note this attribute isn't RFC4530 compliant, but is close enough to work
This can be reversed by:
Once you've done that configure a valid bind user, and bind password and add "cn=accounts" to the start of your baseDN (e.g. cn=accounts,dc=example,dc=com)
Hopefully we can get the Dell guys to query for "ipaUniqueID" as well and use that if "entryUUID" doesn't exist.
Obviously use this with care, it's really not a fix, but it is a nasty hack, and you might not wish to run this on your production FreeIPA.
lukasst
3 Posts
1
July 13th, 2020 23:00
3.4.0 (Build 55) still does not work
redOne
1 Message
0
October 2nd, 2020 06:00
I also see the same query issues that lukasst reports in OpenManage Enterprise Modular 1.20.10. Any comments from support?
Grant_Curell
22 Posts
0
October 14th, 2020 08:00
My name is Grant Curell - I'm just a random Dell software engineer who had a customer happen upon this and they asked me about it. I'm going to go build this out in a lab. If I can replicate it I'll push it to back end engineering and respond here if I find a fix.
If it helps anyone else, as a guy who used to be a customer and is now an engineer, I can tell you that if you want something to get pushed to backend engineering for a fix it generally has to go through a formal support case over the phone associated with a service tag. The help desk guys will create a service request for it, if they can't solve it (which they wouldn't for this in all likelihood), they'll elevate it, someone will confirm it's actually a bug, then someone will prioritize it according to how many people are hollering, and then it will get fixed in priority order.
That all said, as a software engineer myself that just happened to come across this, I personally appreciate the amount of work that has been done to diagnose this problem. Give me a day or two and if I don't get hit with anything else I'll shoot an answer back.
lukasst
3 Posts
0
October 14th, 2020 23:00
@Grant_Curell thank you a lot for any effort put into this. It would be great to have it fixed and working properly.
I tried to open a case with regards to FreeIPA LDAP integration in OME in the past, but support closed it with statement "We are only a Break/Fix hardware team" and that we should request a quote outside of warranty. This was unacceptable for us as we are already paying for enterprise iDRAC.
Thanks a lot for your effort.