Volker,
So the bottom line is that if you set the rid attribute to be something
that does not match the algorithm, things break? This little code resuse
would be one problem :-\ Should be a full search based on the rid value.
I'll look into it.
and before bartlt says anything....i realize that things like
already work in HEAD :-)
/*******************************************************************
run the search by rid.
******************************************************************/
static int ldap_search_one_user_by_rid (LDAP * ldap_struct, uint32 rid,
LDAPMessage ** result)
{
pstring filter;
int rc;
/* check if the user rid exsists, if not, try searching on the uid
*/
snprintf(filter, sizeof(filter) - 1, "rid=%i", rid);
rc = ldap_search_one_user(ldap_struct, filter, result);
if (rc != LDAP_SUCCESS)
rc = ldap_search_one_user_by_uid(ldap_struct,
pdb_user_rid_to_uid(rid), result);
^^^^^^^^^^^^^^^^^^^^^^^^
return rc;
}
jerry
On Wed, 5 Jun 2002 [EMAIL PROTECTED] wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > Can you give more details. I don't understand the problem from
> > this description. I'd like to ensure the ldap backend works
> > correctly for PDC/BDC purposes in 2.2.5.
>
> Sorry for being vague.
>
> PDC/BDC is not the problem. w2kwks is my Windows 2000 Workstation that
> wants to join the domain. Look at the rid field. It does *not* match
> the algorithmic mapping from uid=1004, which would give 3008. I set
> the rid by accident to 3005. I thought this should work, but it does
> not seem to, as the algorithmic setup is spread around everywhere
> except for example in srv_samr_nt.c/line 1400 (SAMR_OPEN_USER) where
> the rid is looked up in LDAP.
>
...
>
> Now I do a rpcclient against a PDC that works against this LDAP backend:
>
> rpcclient $> lookupnames w2kwks$
> w2kwks$ S-1-5-21-1893519152-2010502013-2030181751-3008 (1)
> rpcclient $> samlookuprids 3005
> rid 0xbbd: unix_group.1002 (4)
> rpcclient $> samlookuprids 3008
> rid 0xbc0: w2kwks$ (1)
>
> The workstation tries to change its password by doing a SAMR_OPEN_USER
> on the rid it obtained from an lsalookupnames call. This fails.
