Bug 1305998

Summary:	The deletion of an LDAP domain in keystone when write enabled should not clear the LDAP database
Product:	Red Hat OpenStack	Reporter:	Dan Lavu <dlavu>
Component:	openstack-keystone	Assignee:	Adam Young <ayoung>
Status:	CLOSED WONTFIX	QA Contact:	nlevinki <nlevinki>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.0 (Kilo)	CC:	jdennis, nkinder, srevivo
Target Milestone:	---	Keywords:	ZStream
Target Release:	8.0 (Liberty)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-09-30 02:39:32 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Dan Lavu 2016-02-09 19:15:17 UTC

Description of problem:
Testing multi domain support in RHOS. The deletion of this domain when write enabled cleared the LDAP database entirely. Thankfully this was done in a lab, because LDAP was a total loss. 

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

# rpm -qa | grep packstack
openstack-packstack-puppet-2015.1-0.14.dev1589.g1d6372f.el7ost.noarch
openstack-packstack-2015.1-0.14.dev1589.g1d6372f.el7ost.noarch

# rpm -qa | grep keystone
python-keystoneclient-1.3.0-2.el7ost.noarch
python-keystone-2015.1.2-2.el7ost.noarch
openstack-keystone-2015.1.2-2.el7ost.noarch
python-keystonemiddleware-1.5.1-1.el7ost.noarch

How reproducible:
Assuming always? I was only able to do this once. 


Steps to Reproduce:
1. Enable multi domain support in keystone, ensure the following is in /etc/keystone.conf

[identity]
domain_specific_drivers_enabled = true 
domain_config_dir = /etc/keystone/domains
#default_domain_id = 7d9bed61b1564f2289296a4e9241482d

2. Then add an LDAP domain and ensure that writes are permitted. 

vim /etc/keystone/domains/keystone.laboratory.conf

[ldap]
url=ldap://auth.lab.runlevelone.lan
user=uid=keystone,cn=users,cn=accounts,dc=lab,dc=runlevelone,dc=lan
password=xxxxxxx
suffix=ccn=accounts,dc=lab,dc=runlevelone,dc=lan
user_tree_dn=cn=users,cn=accounts,dc=lab,dc=runlevelone,dc=lan
user_objectclass=person
user_id_attribute=uid
user_name_attribute=uid
user_mail_attribute=mail
user_allow_create=true
user_allow_update=true
user_allow_delete=true
group_tree_dn=cn=groups,cn=accounts,dc=lab,dc=runlevelone,dc=lan
group_objectclass=groupOfNames
group_id_attribute=cn
group_name_attribute=cn
group_member_attribute=member
group_desc_attribute=description
group_allow_create=true
group_allow_update=true
group_allow_delete=true
user_enabled_attribute=nsAccountLock
user_enabled_default=false
user_enabled_invert=true

[identity]
driver = keystone.identity.backends.ldap.Identity


3. Remove the domain, using 'openstack domain delete #domain_id' 



Actual results:
Clears LDAP database, cn=users/groups,cn=accounts,dc=lab,dc=runlevelone,dc=lan was completely empty


Expected results:
Does not delete users on removal or prompt "THIS WILL DELETE ALL USERS, DO YOU WANT TO PROCEED"


Additional info:

Comment 2 Adam Young 2016-09-30 02:39:32 UTC

Latest 2 releases (8 and 9) have removed write support for the LDAP driver. 


Suggest we do the same.  In the case of what you have above, the Keystone server was allowed to write to the LDAP server, which should not be the case.

We should not be running with the values of:

user_allow_create=true
user_allow_update=true
user_allow_delete=true

As that indicates to the User that the Keystone server is in control of the LDAP instance (not a good design).


To provide an addtiona; guard against it, the LDAP user that performs queries against LDAP should not have write access to the database.