Bug 4088 - account policies in LDAP handling
Summary: account policies in LDAP handling
Status: REOPENED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: User/Group Accounts (show other bugs)
Version: 3.0.23b
Hardware: x86 Linux
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-07 10:45 UTC by Holger Schmieder
Modified: 2008-07-01 13:03 UTC (History)
1 user (show)

See Also:


Attachments
output of pdbedit -d10 -P "bad lockout attempt" -C 3 (8.01 KB, text/plain)
2006-09-07 10:46 UTC, Holger Schmieder
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Holger Schmieder 2006-09-07 10:45:30 UTC
I am using samba 3.0.23b with OpenLDAP. Everything is fine but when i try to configure Acount policies with pdbedit this option will not read from or write to ldap, the where set in the local tdb.

Example:
pdbedit -P "min password length"
WARNING: The "printer admin" option is deprecated
smbldap_search_domain_info: Searching for:[(&(objectClass=sambaDomain)(sambaDomainName=TEST.DE))]
smbldap_open_connection: connection opened
smbldap_search_domain_info: Searching for:[(&(objectClass=sambaDomain)(sambaDomainName=TEST.DE))]
smbldap_open_connection: connection opened
account policy "min password length" description: Minimal password length (default: 5)
account policy "min password length" value is: 5

This happens allthough i have set sambaMinPwdLength=10 in TEST.DE (on my LDAP-server)

In the LDAP-logs i saw that only the old attributes like RIDBase where requested while this operation.
Comment 1 Holger Schmieder 2006-09-07 10:46:51 UTC
Created attachment 2130 [details]
output of pdbedit -d10 -P "bad lockout attempt" -C 3
Comment 2 Volker Lendecke 2006-09-07 10:49:19 UTC
It's a known deficiency, closing as "later".

Volker
Comment 3 Holger Schmieder 2006-09-07 10:55:13 UTC
(In reply to comment #2)
> It's a known deficiency, closing as "later".
> 
> Volker
> 
Hello Volker,
is there another bugreport regarding this ? Do you have an idea when this issue will be solved ?
Thanks
Holger
Comment 4 Volker Lendecke 2006-09-09 12:26:43 UTC
Argl, sorry, I was wrong. This is confusing. Before account policies are stored in LDAP at all, you need to migrate them from tdb to LDAP with

pdbedit -i tdbsam -e ldapsam -y

Günther, I would propose to remove this account_policy_migrated flag. We don't do this for groups and users, and I don't see a reason to do it for the policies.

What do you think?

Volker
Comment 5 Gerald (Jerry) Carter (dead mail address) 2006-09-09 13:02:28 UTC
Volker, the manual migration was by my request.  Although,
I willing to automatically migrate the policy settings in the
next release.  Assuming that we know everything is working ok.
Comment 6 Volker Lendecke 2006-09-09 13:07:46 UTC
Sure, agreed. I'm not asking for automatic migration, I'm asking to remove the definite need to do the manual migration.

I would like to have it the same as for users and group mappings: Whatever the passdb backend option says is relevant. This is not the case for account policies. If you change from tdbsam or smbpasswd to ldap, then without explicit migration the account policy values still end up in the tdb.

Changing this would mean that for the caching functionality (do we really need that?) we would have to use another mechanism. gencache might be the appropriate place.

Volker
Comment 7 Gerald (Jerry) Carter (dead mail address) 2006-09-09 13:16:12 UTC
I agree this should work the same as group mapping 
storage and migration.  Let's take it on the tech list 
for more discussion though :-)
Comment 8 Volker Lendecke 2006-09-09 13:17:36 UTC
done :-)

Volker
Comment 9 Björn Jacke 2008-07-01 12:02:04 UTC
comment #6 sounded good. Does anyone remember the result from the tech list discussion?
Comment 10 Guenther Deschner 2008-07-01 13:03:45 UTC
(In reply to comment #9)
> comment #6 sounded good. Does anyone remember the result from the tech list
> discussion?

IIRC, Volker moved at least the caching stuff to gencache.

Just my 2cents.