Bug 679609

Summary:	ipa-server-install when realm != domain puts ldap information in realm.
Product:	[Retired] freeIPA	Reporter:	Erinn Looney-Triggs <erinn.looneytriggs>
Component:	ipa-server	Assignee:	Rob Crittenden <rcritten>
Status:	CLOSED ERRATA	QA Contact:	Chandrasekar Kannan <ckannan>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	2.0	CC:	benl, dpal, jgalipea, jhrozek, sgallagh, ssorce
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	freeipa-2.1.0-1.fc15	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-03-28 09:27:34 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Erinn Looney-Triggs 2011-02-23 00:05:36 UTC

Description of problem:
Ok I am not great with ldap stuff so please stick with me here. I do an install using ipa-server-install on a fedora 14 x64 system. I configured the following settings:
Server host name: ipa.foo.com
Domain name: foo.com
Realm: LINUX.FOO.COM

Install goes fine, now I run a query:
ldapsearch -Y GSSAPI -b "dc=foo,dc=com"

# search result
search: 4
result: 32 No such object

On the other hand:
ldapsearch -Y GSSAPI -b "dc=linux,dc=foo,dc=com"

Returns a whole slew of information. 

I am not sure if this is the way it is supposed to be, if it is than the client is not getting configured correctly with ipa-client-install, lookups of user names fail because it is looking in dc=foo,dc=com (which is configured by default) instead of the correct location. If it is not supposed to be there than this would appear to be a server configuration issue.

Version-Release number of selected component (if applicable):

freeipa-client-2.0.0.rc1-0.fc14.x86_64
freeipa-python-2.0.0.rc1-0.fc14.x86_64
freeipa-admintools-2.0.0.rc1-0.fc14.x86_64
freeipa-server-2.0.0.rc1-0.fc14.x86_64
freeipa-server-selinux-2.0.0.rc1-0.fc14.x86_64

Comment 1 Rob Crittenden 2011-02-23 03:35:20 UTC

https://fedorahosted.org/freeipa/ticket/1001

Need to check with the SSSD team but yes, looks like ipa_domain should be set to the realm name, not the domain name, in sssd.conf.

Comment 2 Erinn Looney-Triggs 2011-02-23 06:17:42 UTC

Indeed setting the ipa_domain to linux.foo.com does resolve the issue and lookups work again. Interestingly the only other reference I could find to the ldap base was in /etc/ipa/default.conf:

[global]
basedn = dc=linux,dc=foo,dc=com

So that at least looks like it is correct, but I can't find much documentation on what it means or is used for.

Comment 3 Jakub Hrozek 2011-02-23 12:41:21 UTC

(In reply to comment #1)
> https://fedorahosted.org/freeipa/ticket/1001
> 
> Need to check with the SSSD team but yes, looks like ipa_domain should be set
> to the realm name, not the domain name, in sssd.conf.

The IPA provider in SSSD derives the base DN from the ipa_domain option.

Comment 4 Rob Crittenden 2011-02-23 16:02:25 UTC

The values /etc/ipa/default.conf are used by the ipa tool and the server. basedn is the LDAP basedn. The default.conf file will get a man page in the next IPA release candidate.

Comment 5 Jakub Hrozek 2011-02-23 16:28:07 UTC

As discussed on IRC, this is a bug in SSSD. Since FreeIPA uses realm to construct the base DN, so should SSSD.

The upstream SSSD bug is:
https://fedorahosted.org/sssd/ticket/807

FreeIPA should only require the fixed version of SSSD.

Comment 6 Rob Crittenden 2011-03-10 21:13:37 UTC

Require sssd 1.5.1-12 or higher in RHEL.