Re: [PATCH] ldap connection caching (not ready!!!)
Stefan (metze) Metzmacher wrote: Hi Andrew, here's the working version of my ldap connection chaching patch with looping (we retry after 0.5, 2, 4.5, 8, 12.5, 18, 24.5 seconds) Been very busy with assignments, but this patch looks good - but can you move the common code into a helper? That is, every loop has a 10 line chunk, can you put that into a helper? Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
Re: [PATCH] ldap connection caching (not ready!!!)
[EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 But we want to add one - and I want it for non-unix accounts. What I propose is that we get the nextrid idea bedded down in non-unix accounts, then expand it from there when we figure out the other issues. I still do not really get the idea of non-unix accounts. What do I use them for? Is it only for machine accounts? Everyone who wants to access a share needs a valid unix uid. Mainly that, but I've also used it for a user that can domain logon, but must never session setup. (Only used for logon to squid-NTLM) Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
Re: [PATCH] ldap connection caching (not ready!!!)
A 'make clean' can do wonders...
this was th efirst thing I do :-)
In any case, what do you mean by 'HEAD works'? Is your patch against
3.0 + your passdb patch or .. ?
I mean clean HEAD without my patch :-)
On the patch - the 'wrapper' functions need to include a while loop.
do {
try again()
} while (error == LDAP_SERVER_DOWN)
shouldn't this be in the ldapsam_open() ?
With appropirate sleep/backoff - see the nss_ldap code for a good
example.
While doing a 'ping' to the server before we start catches most of the
dropout cases, it does add latency (may or may not be an issue), and we
really need to deal with it in the actual operation I think.
??? did you see that I not ping the server every time only all 10 sec
But I'm not shure what you want to say me here :-(
metze
-
Stefan metze Metzmacher [EMAIL PROTECTED]
Re: [PATCH] ldap connection caching (not ready!!!)
At 21:30 17.10.2002 +0200, [EMAIL PROTECTED] wrote:
+++ /home/vlendec/head/source/passdb/pdb_ldap.c Thu Oct 17 21:26:37 2002
@@ -1445,7 +1445,7 @@
} else {
ldap_msgfree(result);
}
- return NT_STATUS_UNSUCCESSFUL;
+ return ret;
}
Hi Volker,
thanks a lot!!! a few line above I read 'return NT_STATUS_OK' but it was
'ret = NT_STATUS_OK' :-(
but now it works! :-)
what I need is to test is the non_unix_account stuff.
I'd preferr to first apply the rid allocator patch! then I make the new
functions use the wrapper functions ...
metze
-
Stefan metze Metzmacher [EMAIL PROTECTED]
Re: [PATCH] ldap connection caching (not ready!!!)
Stefan (metze) Metzmacher wrote: !!! a few line above I read 'return NT_STATUS_OK' but it was 'ret = NT_STATUS_OK' :-( but now it works! :-) what I need is to test is the non_unix_account stuff. I browsed the code and the ldap schema changes... if I don't misunderstand, the the nextrid is used only for non_unix_account, and the algorithmic mapping for unix accounts, rigth? So, the other question is if a non_unix_account should be in only-one domain? In other words: if an user logs in the domain x the ldap stuff will provide a rid-x only useable for the domain-x? I wonder if this may be a strong restriction for large sites with n domains and only-one ldap base... because the administrators should maintain n accounts/rid per-user for access to the n domains. On the other hand, if the domain attr takes n-values may solve the multiple logon but the rid space may be broken. Ignacio -- Ignacio Coupeau, Ph.D. e-mail: [EMAIL PROTECTED] CTI, Director fax:948 425619 University of Navarra voice: 948 425600 Pamplona, SPAINhttp://www.unav.es/cti/
Re: [PATCH] ldap connection caching (not ready!!!)
At 10:30 18.10.2002 +0200, Ignacio Coupeau wrote: Stefan (metze) Metzmacher wrote: !!! a few line above I read 'return NT_STATUS_OK' but it was 'ret = NT_STATUS_OK' :-( but now it works! :-) what I need is to test is the non_unix_account stuff. Should this mail a responde to the id allocator patch??? I browsed the code and the ldap schema changes... if I don't misunderstand, the the nextrid is used only for non_unix_account, and the algorithmic mapping for unix accounts, rigth? there is no nextrid attribute in HEAD or 3_0 So, the other question is if a non_unix_account should be in only-one domain? In other words: if an user logs in the domain x the ldap stuff will provide a rid-x only useable for the domain-x? I wonder if this may be a strong restriction for large sites with n domains and only-one ldap base... because the administrators should maintain n accounts/rid per-user for access to the n domains. On the other hand, if the domain attr takes n-values may solve the multiple logon but the rid space may be broken. you can have only one samba domain in one ldap tree, all samba related objects have only a rid and a full sid and the attribute 'domain' is not used at the moment. metze - Stefan metze Metzmacher [EMAIL PROTECTED]
Re: [PATCH] ldap connection caching (not ready!!!)
Stefan (metze) Metzmacher wrote: At 10:30 18.10.2002 +0200, Ignacio Coupeau wrote: Stefan (metze) Metzmacher wrote: !!! a few line above I read 'return NT_STATUS_OK' but it was 'ret = NT_STATUS_OK' :-( but now it works! :-) what I need is to test is the non_unix_account stuff. Should this mail a responde to the id allocator patch??? I browsed the code and the ldap schema changes... if I don't misunderstand, the the nextrid is used only for non_unix_account, and the algorithmic mapping for unix accounts, rigth? there is no nextrid attribute in HEAD or 3_0 But we want to add one - and I want it for non-unix accounts. What I propose is that we get the nextrid idea bedded down in non-unix accounts, then expand it from there when we figure out the other issues. So, the other question is if a non_unix_account should be in only-one domain? In other words: if an user logs in the domain x the ldap stuff will provide a rid-x only useable for the domain-x? I wonder if this may be a strong restriction for large sites with n domains and only-one ldap base... because the administrators should maintain n accounts/rid per-user for access to the n domains. On the other hand, if the domain attr takes n-values may solve the multiple logon but the rid space may be broken. you can have only one samba domain in one ldap tree, all samba related objects have only a rid and a full sid and the attribute 'domain' is not used at the moment. Well, you should be able to have more than one domain per ldap tree - we should use the ldap suffix, and the ldap search filter to allow it. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
[PATCH] ldap connection caching (not ready!!!)
Hi Andrew,
here's the NOT READY version of my ldap connection chaching patch
metze
-
Stefan metze Metzmacher [EMAIL PROTECTED]
diff -Npur --exclude=CVS --exclude=*.bak --exclude=*.o --exclude=*.po --exclude=.#*
HEAD/source/passdb/pdb_ldap.c HEAD-pdb/source/passdb/pdb_ldap.c
--- HEAD/source/passdb/pdb_ldap.c Thu Oct 17 14:32:53 2002
+++ HEAD-pdb/source/passdb/pdb_ldap.c Thu Oct 17 14:29:57 2002
@@ -681,6 +681,11 @@ static BOOL init_sam_from_ldap (struct l
pstrcpy(nt_username, username);
pstrcpy(domain, lp_workgroup());
+
+ pdb_set_username(sampass, username, PDB_SET);
+
+ pdb_set_domain(sampass, domain, PDB_DEFAULT);
+ pdb_set_nt_username(sampass, nt_username, PDB_SET);
get_single_attribute(ldap_struct, entry, rid, temp);
user_rid = (uint32)atol(temp);
@@ -848,9 +853,10 @@ static BOOL init_sam_from_ldap (struct l
memset(hours, 0xff, hours_len);
if (!get_single_attribute (ldap_struct, entry, lmPassword, temp)) {
- /* leave as default */
+ DEBUG(2,(no lmPassword found for user:
+%s\n,pdb_get_username(sampass)));
} else {
pdb_gethexpwd(temp, smblmpwd);
+ DEBUG(2,(lmPassword found for user: %s
+%s\n,pdb_get_username(sampass),temp));
memset((char *)temp, '\0', strlen(temp)+1);
if (!pdb_set_lanman_passwd(sampass, smblmpwd, PDB_SET))
return False;
@@ -858,9 +864,10 @@ static BOOL init_sam_from_ldap (struct l
}
if (!get_single_attribute (ldap_struct, entry, ntPassword, temp)) {
- /* leave as default */
+ DEBUG(2,(no ntPassword found for user:
+%s\n,pdb_get_username(sampass)));
} else {
pdb_gethexpwd(temp, smbntpwd);
+ DEBUG(2,(ntPassword found for user: %s
+%s\n,pdb_get_username(sampass),temp));
memset((char *)temp, '\0', strlen(temp)+1);
if (!pdb_set_nt_passwd(sampass, smbntpwd, PDB_SET))
return False;
@@ -881,11 +888,6 @@ static BOOL init_sam_from_ldap (struct l
pdb_set_hours_len(sampass, hours_len, PDB_SET);
pdb_set_logon_divs(sampass, logon_divs, PDB_SET);
- pdb_set_username(sampass, username, PDB_SET);
-
- pdb_set_domain(sampass, domain, PDB_DEFAULT);
- pdb_set_nt_username(sampass, nt_username, PDB_SET);
-
pdb_set_munged_dial(sampass, munged_dial, PDB_SET);
/* pdb_set_unknown_3(sampass, unknown3, PDB_SET); */
@@ -1217,6 +1219,50 @@ static uint32 ldapsam_get_next_available
}
/**
+Connect to LDAP server
+*/
+static NTSTATUS ldapsam_open(struct pdb_methods *my_methods)
+{
+ struct ldapsam_privates *ldap_state = (struct ldapsam_privates
+*)my_methods-private_data;
+
+ if (ldap_state-ldap_struct != NULL) {
+ DEBUG(4,(The connection to the LDAP server is up\n));
+ /* maybe we should check if the connection is still up --metze*/
+ return NT_STATUS_OK;
+ }
+
+ if (!ldapsam_open_connection(ldap_state, ldap_state-ldap_struct)) {
+ return NT_STATUS_UNSUCCESSFUL;
+ }
+ if (!ldapsam_connect_system(ldap_state, ldap_state-ldap_struct)) {
+ ldap_unbind(ldap_state-ldap_struct);
+ ldap_state-ldap_struct = NULL;
+ return NT_STATUS_UNSUCCESSFUL;
+ }
+ DEBUG(4,(The LDAP server is succesful connected\n));
+
+ return NT_STATUS_OK;
+}
+
+/**
+Disconnect from LDAP server
+*/
+static NTSTATUS ldapsam_close(struct pdb_methods *my_methods)
+{
+ struct ldapsam_privates *ldap_state = (struct ldapsam_privates
+*)my_methods-private_data;
+
+ if (ldap_state-ldap_struct != NULL) {
+ ldap_unbind(ldap_state-ldap_struct);
+ ldap_state-ldap_struct = NULL;
+ }
+
+ DEBUG(5,(The connection to the LDAP server was closed\n));
+ /* maybe free the results here --metze */
+
+ return NT_STATUS_OK;
+}
+
+/**
Connect to LDAP server for password enumeration
*/
static NTSTATUS ldapsam_setsampwent(struct pdb_methods *my_methods, BOOL update)
@@ -1226,11 +1272,8 @@ static NTSTATUS ldapsam_setsampwent(stru
int rc;
pstring filter;
- if (!ldapsam_open_connection(ldap_state, ldap_state-ldap_struct)) {
- return ret;
- }
- if (!ldapsam_connect_system(ldap_state,
Re: [PATCH] ldap connection caching (not ready!!!)
Stefan (metze) Metzmacher wrote:
Hi Andrew,
here's the next NOT WORKING version of my ldap connection chaching patch
there's a problem with the LM and NT passwords.
I've got the following errors??? Can anybody test it I can't find the bug
:-( I'm sitting here for hours now...
btw the ldap server send's the password, I see them in ethereal. AND HEAD
WORKS!???
A 'make clean' can do wonders...
In any case, what do you mean by 'HEAD works'? Is your patch against
3.0 + your passdb patch or .. ?
On the patch - the 'wrapper' functions need to include a while loop.
do {
try again()
} while (error == LDAP_SERVER_DOWN)
With appropirate sleep/backoff - see the nss_ldap code for a good
example.
While doing a 'ping' to the server before we start catches most of the
dropout cases, it does add latency (may or may not be an issue), and we
really need to deal with it in the actual operation I think.
Andrew Bartlett
--
Andrew Bartlett [EMAIL PROTECTED]
Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED]
Student Network Administrator, Hawker College [EMAIL PROTECTED]
http://samba.org http://build.samba.org http://hawkerc.net
