2003-06-03 18:19:59 +00:00
/*
Unix SMB / CIFS implementation .
idmap LDAP backend
2003-06-05 02:34:30 +00:00
Copyright ( C ) Tim Potter 2000
Copyright ( C ) Anthony Liguori 2003
Copyright ( C ) Simo Sorce 2003
Copyright ( C ) Gerald Carter 2003
2003-06-03 18:19:59 +00:00
This program is free software ; you can redistribute it and / or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation ; either version 2 of the License , or
( at your option ) any later version .
This program is distributed in the hope that it will be useful ,
but WITHOUT ANY WARRANTY ; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE . See the
GNU General Public License for more details .
You should have received a copy of the GNU General Public License
along with this program ; if not , write to the Free Software
Foundation , Inc . , 675 Mass Ave , Cambridge , MA 0213 9 , USA .
*/
# include "includes.h"
# undef DBGC_CLASS
# define DBGC_CLASS DBGC_IDMAP
# include <lber.h>
# include <ldap.h>
2003-06-05 02:34:30 +00:00
# include "smbldap.h"
2003-06-06 13:48:39 +00:00
# define IDMAP_GROUP_SUFFIX "ou=idmap group"
# define IDMAP_USER_SUFFIX "ou=idmap people"
2003-06-05 02:34:30 +00:00
2003-06-03 18:19:59 +00:00
struct ldap_idmap_state {
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
struct smbldap_state * smbldap_state ;
TALLOC_CTX * mem_ctx ;
2003-07-11 05:33:40 +00:00
uint32 low_allocated_user_rid ;
uint32 high_allocated_user_rid ;
uint32 low_allocated_group_rid ;
uint32 high_allocated_group_rid ;
2003-06-03 18:19:59 +00:00
} ;
# define LDAP_MAX_ALLOC_ID 128 / * number tries while allocating
new id */
static struct ldap_idmap_state ldap_state ;
static NTSTATUS ldap_set_mapping ( const DOM_SID * sid , unid_t id , int id_type ) ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
static NTSTATUS ldap_set_mapping_internals ( const DOM_SID * sid , unid_t id , int id_type ,
const char * ldap_dn , LDAPMessage * entry ) ;
2003-06-03 18:19:59 +00:00
static NTSTATUS ldap_idmap_close ( void ) ;
2003-07-11 05:33:40 +00:00
/**********************************************************************
Even if the sambaDomain attribute in LDAP tells us that this RID is
safe to use , always check before use .
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
static BOOL sid_in_use ( struct ldap_idmap_state * state ,
const DOM_SID * sid , int * error )
{
fstring filter ;
fstring sid_string ;
LDAPMessage * result = NULL ;
int count ;
int rc ;
char * sid_attr [ ] = { LDAP_ATTRIBUTE_SID , NULL } ;
slprintf ( filter , sizeof ( filter ) - 1 , " (%s=%s) " , LDAP_ATTRIBUTE_SID , sid_to_string ( sid_string , sid ) ) ;
rc = smbldap_search_suffix ( state - > smbldap_state ,
filter , sid_attr , & result ) ;
if ( rc ! = LDAP_SUCCESS ) {
char * ld_error = NULL ;
ldap_get_option ( state - > smbldap_state - > ldap_struct , LDAP_OPT_ERROR_STRING , & ld_error ) ;
DEBUG ( 2 , ( " Failed to check if sid %s is alredy in use: %s \n " ,
sid_string , ld_error ) ) ;
SAFE_FREE ( ld_error ) ;
* error = rc ;
return True ;
}
if ( ( count = ldap_count_entries ( state - > smbldap_state - > ldap_struct , result ) ) > 0 ) {
DEBUG ( 3 , ( " Sid %s already in use - trying next RID \n " ,
sid_string ) ) ;
ldap_msgfree ( result ) ;
return True ;
}
ldap_msgfree ( result ) ;
/* good, sid is not in use */
return False ;
}
/**********************************************************************
Set the new nextRid attribute , and return one we can use .
This also checks that this RID is actually free - in case the admin
manually stole it : - ) .
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
static NTSTATUS ldap_next_rid ( struct ldap_idmap_state * state , uint32 * rid ,
int rid_type )
{
NTSTATUS ret = NT_STATUS_UNSUCCESSFUL ;
int rc ;
LDAPMessage * domain_result = NULL ;
LDAPMessage * entry = NULL ;
char * dn ;
LDAPMod * * mods = NULL ;
fstring old_rid_string ;
fstring next_rid_string ;
fstring algorithmic_rid_base_string ;
uint32 next_rid ;
uint32 alg_rid_base ;
int attempts = 0 ;
char * ld_error = NULL ;
while ( attempts < 10 )
{
if ( ! NT_STATUS_IS_OK ( ret = smbldap_search_domain_info ( state - > smbldap_state ,
& domain_result , get_global_sam_name ( ) , True ) ) )
{
return ret ;
}
entry = ldap_first_entry ( state - > smbldap_state - > ldap_struct , domain_result ) ;
if ( ! entry ) {
DEBUG ( 0 , ( " Could not get domain info entry \n " ) ) ;
ldap_msgfree ( domain_result ) ;
return ret ;
}
if ( ( dn = ldap_get_dn ( state - > smbldap_state - > ldap_struct , entry ) ) = = NULL ) {
DEBUG ( 0 , ( " Could not get domain info DN \n " ) ) ;
ldap_msgfree ( domain_result ) ;
return ret ;
}
/* yes, we keep 3 seperate counters, one for rids between 1000 (BASE_RID) and
algorithmic_rid_base . The other two are to avoid stomping on the
different sets of algorithmic RIDs */
if ( smbldap_get_single_attribute ( state - > smbldap_state - > ldap_struct , entry ,
get_attr_key2string ( dominfo_attr_list , LDAP_ATTR_ALGORITHMIC_RID_BASE ) ,
algorithmic_rid_base_string ) )
{
alg_rid_base = ( uint32 ) atol ( algorithmic_rid_base_string ) ;
} else {
alg_rid_base = algorithmic_rid_base ( ) ;
/* Try to make the modification atomically by enforcing the
old value in the delete mod . */
slprintf ( algorithmic_rid_base_string , sizeof ( algorithmic_rid_base_string ) - 1 , " %d " , alg_rid_base ) ;
smbldap_make_mod ( state - > smbldap_state - > ldap_struct , entry , & mods ,
get_attr_key2string ( dominfo_attr_list , LDAP_ATTR_ALGORITHMIC_RID_BASE ) ,
algorithmic_rid_base_string ) ;
}
next_rid = 0 ;
if ( alg_rid_base > BASE_RID ) {
/* we have a non-default 'algorithmic rid base', so we have 'low' rids that we
can allocate to new users */
if ( smbldap_get_single_attribute ( state - > smbldap_state - > ldap_struct , entry ,
get_attr_key2string ( dominfo_attr_list , LDAP_ATTR_NEXT_RID ) ,
old_rid_string ) )
{
* rid = ( uint32 ) atol ( old_rid_string ) ;
} else {
* rid = BASE_RID ;
}
next_rid = * rid + 1 ;
if ( next_rid > = alg_rid_base ) {
return NT_STATUS_UNSUCCESSFUL ;
}
slprintf ( next_rid_string , sizeof ( next_rid_string ) - 1 , " %d " , next_rid ) ;
/* Try to make the modification atomically by enforcing the
old value in the delete mod . */
smbldap_make_mod ( state - > smbldap_state - > ldap_struct , entry , & mods ,
get_attr_key2string ( dominfo_attr_list , LDAP_ATTR_NEXT_RID ) ,
next_rid_string ) ;
}
if ( ! next_rid ) { /* not got one already */
switch ( rid_type ) {
case USER_RID_TYPE :
if ( smbldap_get_single_attribute ( state - > smbldap_state - > ldap_struct , entry ,
get_attr_key2string ( dominfo_attr_list , LDAP_ATTR_NEXT_USERRID ) ,
old_rid_string ) )
{
* rid = ( uint32 ) atol ( old_rid_string ) ;
} else {
* rid = state - > low_allocated_user_rid ;
}
break ;
case GROUP_RID_TYPE :
if ( smbldap_get_single_attribute ( state - > smbldap_state - > ldap_struct , entry ,
get_attr_key2string ( dominfo_attr_list , LDAP_ATTR_NEXT_GROUPRID ) ,
old_rid_string ) )
{
* rid = ( uint32 ) atol ( old_rid_string ) ;
} else {
* rid = state - > low_allocated_group_rid ;
}
break ;
}
/* This is the core of the whole routine. If we had
scheme - style closures , there would be a * lot * less code
duplication . . . */
next_rid = * rid + RID_MULTIPLIER ;
slprintf ( next_rid_string , sizeof ( next_rid_string ) - 1 , " %d " , next_rid ) ;
switch ( rid_type ) {
case USER_RID_TYPE :
if ( next_rid > state - > high_allocated_user_rid ) {
return NT_STATUS_UNSUCCESSFUL ;
}
/* Try to make the modification atomically by enforcing the
old value in the delete mod . */
smbldap_make_mod ( state - > smbldap_state - > ldap_struct , entry , & mods ,
get_attr_key2string ( dominfo_attr_list , LDAP_ATTR_NEXT_USERRID ) ,
next_rid_string ) ;
break ;
case GROUP_RID_TYPE :
if ( next_rid > state - > high_allocated_group_rid ) {
return NT_STATUS_UNSUCCESSFUL ;
}
/* Try to make the modification atomically by enforcing the
old value in the delete mod . */
smbldap_make_mod ( state - > smbldap_state - > ldap_struct , entry , & mods ,
get_attr_key2string ( dominfo_attr_list , LDAP_ATTR_NEXT_GROUPRID ) ,
next_rid_string ) ;
break ;
}
}
if ( ( rc = ldap_modify_s ( state - > smbldap_state - > ldap_struct , dn , mods ) ) = = LDAP_SUCCESS ) {
DOM_SID dom_sid ;
DOM_SID sid ;
pstring domain_sid_string ;
int error = 0 ;
if ( ! smbldap_get_single_attribute ( state - > smbldap_state - > ldap_struct , domain_result ,
get_attr_key2string ( dominfo_attr_list , LDAP_ATTR_DOM_SID ) ,
domain_sid_string ) )
{
ldap_mods_free ( mods , True ) ;
ldap_memfree ( dn ) ;
ldap_msgfree ( domain_result ) ;
return ret ;
}
if ( ! string_to_sid ( & dom_sid , domain_sid_string ) ) {
ldap_mods_free ( mods , True ) ;
ldap_memfree ( dn ) ;
ldap_msgfree ( domain_result ) ;
return ret ;
}
ldap_mods_free ( mods , True ) ;
mods = NULL ;
ldap_memfree ( dn ) ;
ldap_msgfree ( domain_result ) ;
sid_copy ( & sid , & dom_sid ) ;
sid_append_rid ( & sid , * rid ) ;
/* check RID is not in use */
if ( sid_in_use ( state , & sid , & error ) ) {
if ( error ) {
return ret ;
}
continue ;
}
return NT_STATUS_OK ;
}
ld_error = NULL ;
ldap_get_option ( state - > smbldap_state - > ldap_struct , LDAP_OPT_ERROR_STRING , & ld_error ) ;
DEBUG ( 2 , ( " Failed to modify rid: %s \n " , ld_error ? ld_error : " (NULL " ) ) ;
SAFE_FREE ( ld_error ) ;
ldap_mods_free ( mods , True ) ;
mods = NULL ;
ldap_memfree ( dn ) ;
dn = NULL ;
ldap_msgfree ( domain_result ) ;
domain_result = NULL ;
{
/* Sleep for a random timeout */
unsigned sleeptime = ( sys_random ( ) * sys_getpid ( ) * attempts ) ;
attempts + = 1 ;
sleeptime % = 100 ;
msleep ( sleeptime ) ;
}
}
DEBUG ( 0 , ( " Failed to set new RID \n " ) ) ;
return ret ;
}
/*****************************************************************************
Allocate a new RID
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
static NTSTATUS ldap_allocate_rid ( uint32 * rid , int rid_type )
{
return ldap_next_rid ( & ldap_state , rid , rid_type ) ;
}
2003-06-05 02:34:30 +00:00
/*****************************************************************************
Allocate a new uid or gid
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
2003-06-03 18:19:59 +00:00
static NTSTATUS ldap_allocate_id ( unid_t * id , int id_type )
{
NTSTATUS ret = NT_STATUS_UNSUCCESSFUL ;
int rc = LDAP_SERVER_DOWN ;
int count = 0 ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
LDAPMessage * result = NULL ;
LDAPMessage * entry = NULL ;
2003-06-03 18:19:59 +00:00
pstring id_str , new_id_str ;
2003-06-06 13:48:39 +00:00
LDAPMod * * mods = NULL ;
2003-06-05 02:34:30 +00:00
const char * type ;
2003-06-03 18:19:59 +00:00
char * dn ;
2003-06-05 02:34:30 +00:00
char * * attr_list ;
pstring filter ;
2003-06-06 13:48:39 +00:00
uid_t luid , huid ;
gid_t lgid , hgid ;
2003-06-05 02:34:30 +00:00
2003-06-03 18:19:59 +00:00
2003-06-05 02:34:30 +00:00
type = ( id_type & ID_USERID ) ?
get_attr_key2string ( idpool_attr_list , LDAP_ATTR_UIDNUMBER ) :
get_attr_key2string ( idpool_attr_list , LDAP_ATTR_GIDNUMBER ) ;
2003-07-23 12:33:59 +00:00
pstr_sprintf ( filter , " (objectClass=%s) " , LDAP_OBJ_IDPOOL ) ;
2003-06-05 02:34:30 +00:00
attr_list = get_attr_list ( idpool_attr_list ) ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
rc = smbldap_search ( ldap_state . smbldap_state , lp_ldap_idmap_suffix ( ) ,
2003-06-05 02:34:30 +00:00
LDAP_SCOPE_SUBTREE , filter ,
attr_list , 0 , & result ) ;
free_attr_list ( attr_list ) ;
2003-06-03 18:19:59 +00:00
if ( rc ! = LDAP_SUCCESS ) {
2003-06-05 02:34:30 +00:00
DEBUG ( 0 , ( " ldap_allocate_id: %s object not found \n " , LDAP_OBJ_IDPOOL ) ) ;
2003-06-03 18:19:59 +00:00
goto out ;
}
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
count = ldap_count_entries ( ldap_state . smbldap_state - > ldap_struct , result ) ;
2003-06-03 18:19:59 +00:00
if ( count ! = 1 ) {
2003-06-05 02:34:30 +00:00
DEBUG ( 0 , ( " ldap_allocate_id: single %s object not found \n " , LDAP_OBJ_IDPOOL ) ) ;
2003-06-03 18:19:59 +00:00
goto out ;
}
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
dn = ldap_get_dn ( ldap_state . smbldap_state - > ldap_struct , result ) ;
entry = ldap_first_entry ( ldap_state . smbldap_state - > ldap_struct , result ) ;
2003-06-03 18:19:59 +00:00
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
if ( ! smbldap_get_single_attribute ( ldap_state . smbldap_state - > ldap_struct , entry , type , id_str ) ) {
2003-06-03 18:19:59 +00:00
DEBUG ( 0 , ( " ldap_allocate_id: %s attribute not found \n " ,
type ) ) ;
goto out ;
}
2003-06-06 13:48:39 +00:00
/* this must succeed or else we wouldn't have initialized */
lp_idmap_uid ( & luid , & huid ) ;
lp_idmap_gid ( & lgid , & hgid ) ;
2003-06-05 02:34:30 +00:00
2003-06-06 13:48:39 +00:00
/* make sure we still have room to grow */
if ( id_type & ID_USERID ) {
2003-06-03 18:19:59 +00:00
id - > uid = strtoul ( id_str , NULL , 10 ) ;
2003-06-06 13:48:39 +00:00
if ( id - > uid > huid ) {
2003-07-22 04:31:20 +00:00
DEBUG ( 0 , ( " ldap_allocate_id: Cannot allocate uid above %lu! \n " ,
( unsigned long ) huid ) ) ;
2003-06-06 13:48:39 +00:00
goto out ;
}
}
else {
2003-06-03 18:19:59 +00:00
id - > gid = strtoul ( id_str , NULL , 10 ) ;
2003-06-06 13:48:39 +00:00
if ( id - > gid > hgid ) {
2003-07-22 04:31:20 +00:00
DEBUG ( 0 , ( " ldap_allocate_id: Cannot allocate gid above %lu! \n " ,
( unsigned long ) hgid ) ) ;
2003-06-06 13:48:39 +00:00
goto out ;
}
}
2003-06-05 02:34:30 +00:00
2003-07-23 12:33:59 +00:00
pstr_sprintf ( new_id_str , " %lu " ,
2003-07-22 04:31:20 +00:00
( ( id_type & ID_USERID ) ? ( unsigned long ) id - > uid :
( unsigned long ) id - > gid ) + 1 ) ;
2003-06-06 13:48:39 +00:00
2003-06-21 00:45:03 +00:00
smbldap_set_mod ( & mods , LDAP_MOD_DELETE , type , id_str ) ;
smbldap_set_mod ( & mods , LDAP_MOD_ADD , type , new_id_str ) ;
2003-06-05 02:34:30 +00:00
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
rc = ldap_modify_s ( ldap_state . smbldap_state - > ldap_struct , dn , mods ) ;
2003-06-05 02:34:30 +00:00
2003-06-03 18:19:59 +00:00
ldap_memfree ( dn ) ;
2003-06-06 13:48:39 +00:00
ldap_mods_free ( mods , True ) ;
2003-06-05 02:34:30 +00:00
if ( rc ! = LDAP_SUCCESS ) {
DEBUG ( 0 , ( " ldap_allocate_id: Failed to allocate new %s. ldap_modify() failed. \n " ,
type ) ) ;
goto out ;
}
ret = NT_STATUS_OK ;
2003-06-03 18:19:59 +00:00
out :
return ret ;
}
2003-06-05 02:34:30 +00:00
/*****************************************************************************
get a sid from an id
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
2003-06-03 18:19:59 +00:00
static NTSTATUS ldap_get_sid_from_id ( DOM_SID * sid , unid_t id , int id_type )
{
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
LDAPMessage * result = NULL ;
LDAPMessage * entry = NULL ;
fstring id_str ;
2003-06-03 18:19:59 +00:00
pstring sid_str ;
pstring filter ;
2003-06-06 13:48:39 +00:00
pstring suffix ;
2003-06-05 02:34:30 +00:00
const char * type ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
const char * obj_class ;
2003-06-03 18:19:59 +00:00
int rc ;
int count ;
NTSTATUS ret = NT_STATUS_UNSUCCESSFUL ;
2003-06-05 02:34:30 +00:00
char * * attr_list ;
/* first we try for a samba user or group mapping */
if ( id_type & ID_USERID ) {
2003-06-06 13:48:39 +00:00
type = get_attr_key2string ( idpool_attr_list , LDAP_ATTR_UIDNUMBER ) ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
obj_class = LDAP_OBJ_SAMBASAMACCOUNT ;
2003-07-23 12:33:59 +00:00
fstr_sprintf ( id_str , " %lu " , ( unsigned long ) id . uid ) ;
2003-06-06 13:48:39 +00:00
pstrcpy ( suffix , lp_ldap_suffix ( ) ) ;
2003-06-05 02:34:30 +00:00
}
else {
2003-06-06 13:48:39 +00:00
type = get_attr_key2string ( idpool_attr_list , LDAP_ATTR_GIDNUMBER ) ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
obj_class = LDAP_OBJ_GROUPMAP ;
2003-07-23 12:33:59 +00:00
fstr_sprintf ( id_str , " %lu " , ( unsigned long ) id . gid ) ;
2003-06-06 13:48:39 +00:00
pstrcpy ( suffix , lp_ldap_group_suffix ( ) ) ;
2003-06-05 02:34:30 +00:00
}
attr_list = get_attr_list ( sidmap_attr_list ) ;
2003-07-23 12:33:59 +00:00
pstr_sprintf ( filter , " (&(|(objectClass=%s)(objectClass=%s))(%s=%s)) " ,
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
LDAP_OBJ_IDMAP_ENTRY , obj_class , type , id_str ) ;
rc = smbldap_search ( ldap_state . smbldap_state , suffix , LDAP_SCOPE_SUBTREE ,
filter , attr_list , 0 , & result ) ;
2003-06-03 18:19:59 +00:00
2003-06-05 02:34:30 +00:00
if ( rc ! = LDAP_SUCCESS )
goto out ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
count = ldap_count_entries ( ldap_state . smbldap_state - > ldap_struct , result ) ;
2003-06-05 02:34:30 +00:00
/* fall back to looking up an idmap entry if we didn't find and
actual user or group */
2003-06-03 18:19:59 +00:00
if ( count = = 0 ) {
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
ldap_msgfree ( result ) ;
result = NULL ;
2003-07-23 12:33:59 +00:00
pstr_sprintf ( filter , " (&(objectClass=%s)(%s=%lu)) " ,
2003-07-22 04:31:20 +00:00
LDAP_OBJ_IDMAP_ENTRY , type ,
( ( id_type & ID_USERID ) ? ( unsigned long ) id . uid :
( unsigned long ) id . gid ) ) ;
2003-06-06 13:48:39 +00:00
pstrcpy ( suffix , lp_ldap_idmap_suffix ( ) ) ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
rc = smbldap_search ( ldap_state . smbldap_state , suffix , LDAP_SCOPE_SUBTREE ,
2003-06-06 13:48:39 +00:00
filter , attr_list , 0 , & result ) ;
2003-06-05 02:34:30 +00:00
if ( rc ! = LDAP_SUCCESS )
2003-06-03 18:19:59 +00:00
goto out ;
2003-06-05 02:34:30 +00:00
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
count = ldap_count_entries ( ldap_state . smbldap_state - > ldap_struct , result ) ;
2003-06-03 18:19:59 +00:00
}
if ( count ! = 1 ) {
2003-07-22 04:31:20 +00:00
DEBUG ( 0 , ( " ldap_get_sid_from_id: mapping not found for %s: %lu \n " ,
type , ( ( id_type & ID_USERID ) ? ( unsigned long ) id . uid :
( unsigned long ) id . gid ) ) ) ;
2003-06-03 18:19:59 +00:00
goto out ;
}
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
entry = ldap_first_entry ( ldap_state . smbldap_state - > ldap_struct , result ) ;
2003-06-03 18:19:59 +00:00
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
if ( ! smbldap_get_single_attribute ( ldap_state . smbldap_state - > ldap_struct , entry , LDAP_ATTRIBUTE_SID , sid_str ) )
2003-06-03 18:19:59 +00:00
goto out ;
2003-06-05 02:34:30 +00:00
if ( ! string_to_sid ( sid , sid_str ) )
2003-06-03 18:19:59 +00:00
goto out ;
ret = NT_STATUS_OK ;
out :
2003-06-05 02:34:30 +00:00
free_attr_list ( attr_list ) ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
if ( result )
ldap_msgfree ( result ) ;
2003-06-03 18:19:59 +00:00
return ret ;
}
2003-06-05 02:34:30 +00:00
/***********************************************************************
Get an id from a sid
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
static NTSTATUS ldap_get_id_from_sid ( unid_t * id , int * id_type , const DOM_SID * sid )
2003-06-03 18:19:59 +00:00
{
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
LDAPMessage * result = NULL ;
LDAPMessage * entry = NULL ;
2003-06-03 18:19:59 +00:00
pstring sid_str ;
pstring filter ;
pstring id_str ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
const char * suffix ;
2003-06-05 02:34:30 +00:00
const char * type ;
const char * obj_class ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
const char * posix_obj_class ;
2003-06-03 18:19:59 +00:00
int rc ;
int count ;
2003-06-05 02:34:30 +00:00
char * * attr_list ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
char * dn = NULL ;
2003-06-03 18:19:59 +00:00
NTSTATUS ret = NT_STATUS_UNSUCCESSFUL ;
2003-06-05 02:34:30 +00:00
/* first try getting the mapping from a samba user or group */
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
sid_to_string ( sid_str , sid ) ;
2003-06-05 02:34:30 +00:00
if ( * id_type & ID_USERID ) {
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
type = get_attr_key2string ( sidmap_attr_list , LDAP_ATTR_UIDNUMBER ) ;
2003-06-05 02:34:30 +00:00
obj_class = LDAP_OBJ_SAMBASAMACCOUNT ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
posix_obj_class = LDAP_OBJ_POSIXACCOUNT ;
suffix = lp_ldap_suffix ( ) ;
2003-07-23 12:33:59 +00:00
pstr_sprintf ( filter , " (&(|(&(objectClass=%s)(objectClass=%s))(objectClass=%s))(%s=%s)) " ,
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
obj_class , posix_obj_class , LDAP_OBJ_IDMAP_ENTRY ,
get_attr_key2string ( sidmap_attr_list , LDAP_ATTR_SID ) ,
sid_str ) ;
2003-06-05 02:34:30 +00:00
}
else {
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
type = get_attr_key2string ( sidmap_attr_list , LDAP_ATTR_GIDNUMBER ) ;
2003-06-05 02:34:30 +00:00
obj_class = LDAP_OBJ_GROUPMAP ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
posix_obj_class = LDAP_OBJ_POSIXGROUP ;
suffix = lp_ldap_group_suffix ( ) ;
2003-07-23 12:33:59 +00:00
pstr_sprintf ( filter , " (&(|(objectClass=%s)(objectClass=%s))(%s=%s)) " ,
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
obj_class , LDAP_OBJ_IDMAP_ENTRY ,
get_attr_key2string ( sidmap_attr_list , LDAP_ATTR_SID ) ,
sid_str ) ;
}
2003-06-03 18:19:59 +00:00
2003-06-05 02:34:30 +00:00
attr_list = get_attr_list ( sidmap_attr_list ) ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
rc = smbldap_search ( ldap_state . smbldap_state , suffix , LDAP_SCOPE_SUBTREE ,
2003-06-05 02:34:30 +00:00
filter , attr_list , 0 , & result ) ;
if ( rc ! = LDAP_SUCCESS )
2003-06-03 18:19:59 +00:00
goto out ;
2003-06-05 02:34:30 +00:00
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
count = ldap_count_entries ( ldap_state . smbldap_state - > ldap_struct , result ) ;
2003-06-05 02:34:30 +00:00
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
/* fall back to looking up an idmap entry if we didn't find anything under the idmap
user or group suffix */
2003-06-05 02:34:30 +00:00
2003-06-03 18:19:59 +00:00
if ( count = = 0 ) {
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
ldap_msgfree ( result ) ;
2003-07-23 12:33:59 +00:00
pstr_sprintf ( filter , " (&(objectClass=%s)(%s=%s)) " ,
2003-06-05 02:34:30 +00:00
LDAP_OBJ_IDMAP_ENTRY , LDAP_ATTRIBUTE_SID , sid_str ) ;
2003-06-03 18:19:59 +00:00
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
suffix = lp_ldap_idmap_suffix ( ) ;
2003-06-06 13:48:39 +00:00
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
rc = smbldap_search ( ldap_state . smbldap_state , suffix , LDAP_SCOPE_SUBTREE ,
2003-06-06 13:48:39 +00:00
filter , attr_list , 0 , & result ) ;
2003-06-05 02:34:30 +00:00
if ( rc ! = LDAP_SUCCESS )
goto out ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
count = ldap_count_entries ( ldap_state . smbldap_state - > ldap_struct , result ) ;
2003-06-03 18:19:59 +00:00
}
2003-06-05 02:34:30 +00:00
if ( count > 1 ) {
DEBUG ( 0 , ( " ldap_get_id_from_sid: search %s returned more than on entry! \n " ,
filter ) ) ;
2003-06-03 18:19:59 +00:00
goto out ;
}
2003-06-05 02:34:30 +00:00
/* we might have an existing entry to work with so pull out the requested information */
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
if ( count ) {
entry = ldap_first_entry ( ldap_state . smbldap_state - > ldap_struct , result ) ;
2003-06-05 02:34:30 +00:00
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
dn = ldap_get_dn ( ldap_state . smbldap_state - > ldap_struct , result ) ;
DEBUG ( 10 , ( " Found mapping entry at dn=%s, looking for %s \n " , dn , type ) ) ;
if ( smbldap_get_single_attribute ( ldap_state . smbldap_state - > ldap_struct , entry , type , id_str ) )
{
if ( ( * id_type & ID_USERID ) )
id - > uid = strtoul ( id_str , NULL , 10 ) ;
else
id - > gid = strtoul ( id_str , NULL , 10 ) ;
ret = NT_STATUS_OK ;
goto out ;
}
}
2003-06-05 02:34:30 +00:00
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
if ( ! ( * id_type & ID_QUERY_ONLY ) ) {
/* if entry == NULL, and we are asked to - allocate a new id */
2003-06-05 02:34:30 +00:00
int i ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
2003-06-05 02:34:30 +00:00
for ( i = 0 ; i < LDAP_MAX_ALLOC_ID ; i + + )
{
ret = ldap_allocate_id ( id , * id_type ) ;
if ( NT_STATUS_IS_OK ( ret ) )
break ;
2003-06-03 18:19:59 +00:00
}
2003-06-05 02:34:30 +00:00
if ( ! NT_STATUS_IS_OK ( ret ) ) {
DEBUG ( 0 , ( " ldap_allocate_id: cannot acquire id lock! \n " ) ) ;
goto out ;
}
ret = ldap_set_mapping ( sid , * id , * id_type ) ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
} else {
/* no match, and not adding one */
ret = NT_STATUS_UNSUCCESSFUL ;
2003-06-03 18:19:59 +00:00
}
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
2003-06-03 18:19:59 +00:00
out :
2003-06-05 02:34:30 +00:00
free_attr_list ( attr_list ) ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
if ( result )
ldap_msgfree ( result ) ;
if ( dn )
ldap_memfree ( dn ) ;
2003-06-05 02:34:30 +00:00
2003-06-03 18:19:59 +00:00
return ret ;
}
2003-06-05 02:34:30 +00:00
/***********************************************************************
This function cannot be called to modify a mapping , only set a new one
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
This takes a possible pointer to the existing entry for the UID or SID
involved .
2003-06-05 02:34:30 +00:00
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
static NTSTATUS ldap_set_mapping_internals ( const DOM_SID * sid , unid_t id ,
int id_type , const char * ldap_dn ,
LDAPMessage * entry )
2003-06-03 18:19:59 +00:00
{
2003-07-23 12:33:59 +00:00
pstring dn ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
pstring id_str ;
2003-06-06 13:48:39 +00:00
fstring type ;
LDAPMod * * mods = NULL ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
int rc = - 1 ;
int ldap_op ;
fstring sid_string ;
2003-07-05 10:39:41 +00:00
char * * values = NULL ;
2003-07-05 05:19:28 +00:00
int i ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
sid_to_string ( sid_string , sid ) ;
if ( ldap_dn ) {
DEBUG ( 10 , ( " Adding new IDMAP mapping on DN: %s " , ldap_dn ) ) ;
ldap_op = LDAP_MOD_REPLACE ;
2003-07-23 12:33:59 +00:00
pstrcpy ( dn , ldap_dn ) ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
} else {
ldap_op = LDAP_MOD_ADD ;
2003-07-23 12:33:59 +00:00
pstr_sprintf ( dn , " %s=%s,%s " , get_attr_key2string ( sidmap_attr_list , LDAP_ATTR_SID ) ,
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
sid_string , lp_ldap_idmap_suffix ( ) ) ;
}
2003-06-05 02:34:30 +00:00
if ( id_type & ID_USERID )
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
fstrcpy ( type , get_attr_key2string ( sidmap_attr_list , LDAP_ATTR_UIDNUMBER ) ) ;
2003-06-05 02:34:30 +00:00
else
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
fstrcpy ( type , get_attr_key2string ( sidmap_attr_list , LDAP_ATTR_GIDNUMBER ) ) ;
2003-06-03 18:19:59 +00:00
2003-07-23 12:33:59 +00:00
pstr_sprintf ( id_str , " %lu " , ( ( id_type & ID_USERID ) ? ( unsigned long ) id . uid :
2003-07-22 04:31:20 +00:00
( unsigned long ) id . gid ) ) ;
2003-06-05 02:34:30 +00:00
2003-07-05 10:39:41 +00:00
if ( entry )
values = ldap_get_values ( ldap_state . smbldap_state - > ldap_struct , entry , " objectClass " ) ;
2003-07-05 05:19:28 +00:00
if ( values ) {
BOOL found_idmap = False ;
for ( i = 0 ; values [ i ] ; i + + ) {
if ( StrCaseCmp ( values [ i ] , LDAP_OBJ_IDMAP_ENTRY ) = = 0 ) {
found_idmap = True ;
break ;
}
}
if ( ! found_idmap )
smbldap_set_mod ( & mods , LDAP_MOD_ADD ,
" objectClass " , LDAP_OBJ_IDMAP_ENTRY ) ;
} else {
smbldap_set_mod ( & mods , LDAP_MOD_ADD ,
" objectClass " , LDAP_OBJ_IDMAP_ENTRY ) ;
}
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
smbldap_make_mod ( ldap_state . smbldap_state - > ldap_struct ,
entry , & mods , type , id_str ) ;
2003-06-03 18:19:59 +00:00
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
smbldap_make_mod ( ldap_state . smbldap_state - > ldap_struct ,
entry , & mods ,
get_attr_key2string ( sidmap_attr_list , LDAP_ATTR_SID ) ,
sid_string ) ;
2003-07-05 05:19:28 +00:00
/* There may well be nothing at all to do */
if ( mods ) {
switch ( ldap_op )
{
case LDAP_MOD_ADD :
smbldap_set_mod ( & mods , LDAP_MOD_ADD ,
" objectClass " , LDAP_OBJ_SID_ENTRY ) ;
rc = smbldap_add ( ldap_state . smbldap_state , dn , mods ) ;
break ;
case LDAP_MOD_REPLACE :
rc = smbldap_modify ( ldap_state . smbldap_state , dn , mods ) ;
break ;
}
ldap_mods_free ( mods , True ) ;
} else {
rc = LDAP_SUCCESS ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
}
2003-06-06 13:48:39 +00:00
2003-06-03 18:19:59 +00:00
if ( rc ! = LDAP_SUCCESS ) {
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
char * ld_error = NULL ;
ldap_get_option ( ldap_state . smbldap_state - > ldap_struct , LDAP_OPT_ERROR_STRING ,
& ld_error ) ;
2003-07-22 04:31:20 +00:00
DEBUG ( 0 , ( " ldap_set_mapping_internals: Failed to %s mapping from %s to %lu [%s] \n " ,
2003-07-06 05:51:20 +00:00
( ldap_op = = LDAP_MOD_ADD ) ? " add " : " replace " ,
2003-07-22 04:31:20 +00:00
sid_string , ( unsigned long ) ( ( id_type & ID_USERID ) ? id . uid : id . gid ) , type ) ) ;
2003-07-06 05:51:20 +00:00
DEBUG ( 0 , ( " ldap_set_mapping_internals: Error was: %s (%s) \n " , ld_error ? ld_error : " (NULL) " , ldap_err2string ( rc ) ) ) ;
2003-06-03 18:19:59 +00:00
return NT_STATUS_UNSUCCESSFUL ;
}
2003-06-05 02:34:30 +00:00
2003-07-22 04:31:20 +00:00
DEBUG ( 10 , ( " ldap_set_mapping: Successfully created mapping from %s to %lu [%s] \n " ,
sid_string , ( ( id_type & ID_USERID ) ? ( unsigned long ) id . uid :
( unsigned long ) id . gid ) , type ) ) ;
2003-06-03 18:19:59 +00:00
return NT_STATUS_OK ;
}
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
/***********************************************************************
This function cannot be called to modify a mapping , only set a new one
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
static NTSTATUS ldap_set_mapping ( const DOM_SID * sid , unid_t id , int id_type )
{
NTSTATUS ret = NT_STATUS_UNSUCCESSFUL ;
char * dn = NULL ;
LDAPMessage * result = NULL ;
LDAPMessage * entry = NULL ;
const char * type ;
const char * obj_class ;
const char * posix_obj_class ;
const char * suffix ;
fstring sid_str ;
fstring id_str ;
pstring filter ;
char * * attr_list ;
int rc ;
int count ;
/* try for a samba user or group mapping (looking for an entry with a SID) */
if ( id_type & ID_USERID ) {
obj_class = LDAP_OBJ_SAMBASAMACCOUNT ;
suffix = lp_ldap_suffix ( ) ;
type = get_attr_key2string ( idpool_attr_list , LDAP_ATTR_UIDNUMBER ) ;
posix_obj_class = LDAP_OBJ_POSIXACCOUNT ;
2003-07-23 12:33:59 +00:00
fstr_sprintf ( id_str , " %u " , id . uid ) ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
}
else {
obj_class = LDAP_OBJ_GROUPMAP ;
suffix = lp_ldap_group_suffix ( ) ;
type = get_attr_key2string ( idpool_attr_list , LDAP_ATTR_GIDNUMBER ) ;
posix_obj_class = LDAP_OBJ_POSIXGROUP ;
2003-07-23 12:33:59 +00:00
fstr_sprintf ( id_str , " %u " , id . gid ) ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
}
sid_to_string ( sid_str , sid ) ;
2003-07-23 12:33:59 +00:00
pstr_sprintf ( filter ,
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
" (| "
" (&(|(objectClass=%s)(|(objectClass=%s)(objectClass=%s)))(%s=%s)) "
" (&(objectClass=%s)(%s=%s)) "
" ) " ,
/* objectClasses that might contain a SID */
LDAP_OBJ_SID_ENTRY , LDAP_OBJ_IDMAP_ENTRY , obj_class ,
get_attr_key2string ( sidmap_attr_list , LDAP_ATTR_SID ) ,
sid_str ,
/* objectClasses that might contain a Unix UID/GID */
posix_obj_class ,
/* Unix UID/GID specifier*/
type ,
/* actual ID */
id_str ) ;
attr_list = get_attr_list ( sidmap_attr_list ) ;
rc = smbldap_search ( ldap_state . smbldap_state , suffix , LDAP_SCOPE_SUBTREE ,
filter , attr_list , 0 , & result ) ;
free_attr_list ( attr_list ) ;
if ( rc ! = LDAP_SUCCESS )
goto out ;
count = ldap_count_entries ( ldap_state . smbldap_state - > ldap_struct , result ) ;
/* fall back to looking up an idmap entry if we didn't find anything under the idmap
user or group suffix */
if ( count = = 1 ) {
entry = ldap_first_entry ( ldap_state . smbldap_state - > ldap_struct , result ) ;
dn = ldap_get_dn ( ldap_state . smbldap_state - > ldap_struct , result ) ;
DEBUG ( 10 , ( " Found partial mapping entry at dn=%s, looking for %s \n " , dn , type ) ) ;
ret = ldap_set_mapping_internals ( sid , id , id_type , dn , entry ) ;
goto out ;
} else if ( count > 1 ) {
DEBUG ( 0 , ( " Too many entries trying to find DN to attach ldap \n " ) ) ;
goto out ;
}
ret = ldap_set_mapping_internals ( sid , id , id_type , NULL , NULL ) ;
out :
if ( result )
ldap_msgfree ( result ) ;
if ( dn )
ldap_memfree ( dn ) ;
return ret ;
}
2003-06-03 18:19:59 +00:00
/*****************************************************************************
Initialise idmap database .
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
2003-06-06 13:48:39 +00:00
static NTSTATUS ldap_idmap_init ( char * params )
2003-06-03 18:19:59 +00:00
{
2003-06-06 13:48:39 +00:00
fstring filter ;
int rc ;
char * * attr_list ;
LDAPMessage * result = NULL ;
LDAPMod * * mods = NULL ;
int count ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
NTSTATUS nt_status ;
2003-06-06 13:48:39 +00:00
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
ldap_state . mem_ctx = talloc_init ( " idmap_ldap " ) ;
if ( ! ldap_state . mem_ctx ) {
return NT_STATUS_NO_MEMORY ;
}
/* assume location is the only parameter */
if ( ! NT_STATUS_IS_OK ( nt_status =
smbldap_init ( ldap_state . mem_ctx , params ,
& ldap_state . smbldap_state ) ) ) {
talloc_destroy ( ldap_state . mem_ctx ) ;
return nt_status ;
}
2003-06-06 13:48:39 +00:00
/* see if the idmap suffix and sub entries exists */
2003-07-23 12:33:59 +00:00
fstr_sprintf ( filter , " (objectclass=%s) " , LDAP_OBJ_IDPOOL ) ;
2003-06-06 13:48:39 +00:00
attr_list = get_attr_list ( idpool_attr_list ) ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
rc = smbldap_search ( ldap_state . smbldap_state , lp_ldap_idmap_suffix ( ) ,
2003-06-06 13:48:39 +00:00
LDAP_SCOPE_SUBTREE , filter , attr_list , 0 , & result ) ;
free_attr_list ( attr_list ) ;
if ( rc ! = LDAP_SUCCESS )
return NT_STATUS_UNSUCCESSFUL ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
count = ldap_count_entries ( ldap_state . smbldap_state - > ldap_struct , result ) ;
2003-06-06 13:48:39 +00:00
if ( count > 1 ) {
DEBUG ( 0 , ( " ldap_idmap_init: multiple entries returned from %s (base == %s) \n " ,
filter , lp_ldap_idmap_suffix ( ) ) ) ;
return NT_STATUS_UNSUCCESSFUL ;
}
else if ( count = = 0 ) {
uid_t luid , huid ;
gid_t lgid , hgid ;
fstring uid_str , gid_str ;
if ( ! lp_idmap_uid ( & luid , & huid ) | | ! lp_idmap_gid ( & lgid , & hgid ) ) {
DEBUG ( 0 , ( " ldap_idmap_init: idmap uid/gid parameters not specified \n " ) ) ;
return NT_STATUS_UNSUCCESSFUL ;
}
2003-07-23 12:33:59 +00:00
fstr_sprintf ( uid_str , " %d " , luid ) ;
fstr_sprintf ( gid_str , " %d " , lgid ) ;
2003-06-06 13:48:39 +00:00
2003-06-21 00:45:03 +00:00
smbldap_set_mod ( & mods , LDAP_MOD_ADD , " objectClass " , LDAP_OBJ_IDPOOL ) ;
smbldap_set_mod ( & mods , LDAP_MOD_ADD ,
2003-06-06 13:48:39 +00:00
get_attr_key2string ( idpool_attr_list , LDAP_ATTR_UIDNUMBER ) , uid_str ) ;
2003-06-21 00:45:03 +00:00
smbldap_set_mod ( & mods , LDAP_MOD_ADD ,
2003-06-06 13:48:39 +00:00
get_attr_key2string ( idpool_attr_list , LDAP_ATTR_GIDNUMBER ) , gid_str ) ;
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
rc = smbldap_modify ( ldap_state . smbldap_state , lp_ldap_idmap_suffix ( ) , mods ) ;
2003-06-06 13:48:39 +00:00
}
2003-06-03 18:19:59 +00:00
return NT_STATUS_OK ;
}
2003-06-05 02:34:30 +00:00
/*****************************************************************************
End the LDAP session
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
2003-06-03 18:19:59 +00:00
static NTSTATUS ldap_idmap_close ( void )
{
2003-06-06 13:48:39 +00:00
This patch cleans up some of our ldap code, for better behaviour:
We now always read the Domain SID out of LDAP. If the local secrets.tdb
is ever different to LDAP, it is overwritten out of LDAP. We also
store the 'algorithmic rid base' into LDAP, and assert if it changes.
(This ensures cross-host synchronisation, and allows for possible
integration with idmap). If we fail to read/add the domain entry, we just
fallback to the old behaviour.
We always use an existing DN when adding IDMAP entries to LDAP, unless
no suitable entry is available. This means that a user's posixAccount
will have a SID added to it, or a user's sambaSamAccount will have a UID
added. Where we cannot us an existing DN, we use
'sambaSid=S-x-y-z,....' as the DN.
The code now allows modifications to the ID mapping in many cases.
Likewise, we now check more carefully when adding new user entires to LDAP,
to not duplicate SIDs (for users, at this stage), and to add the sambaSamAccount
onto the idmap entry for that user, if it is already established (ensuring
we do not duplicate sambaSid entries in the directory).
The allocated UID code has been expanded to take into account the space
between '1000 - algorithmic rid base'. This much better fits into what
an NT4 does - allocating in the bottom part of the RID range.
On the code cleanup side of things, we now share as much code as
possible between idmap_ldap and pdb_ldap.
We also no longer use the race-prone 'enumerate all users' method for
finding the next RID to allocate. Instead, we just start at the bottom
of the range, and increment again if the user already exists. The first
time this is run, it may well take a long time, but next time will just
be able to use the next Rid.
Thanks to metze and AB for double-checking parts of this.
Andrew Bartlett
(This used to be commit 9c595c8c2327b92a86901d84c3f2c284dabd597e)
2003-07-04 13:29:42 +00:00
smbldap_free_struct ( & ( ldap_state ) . smbldap_state ) ;
talloc_destroy ( ldap_state . mem_ctx ) ;
2003-06-03 18:19:59 +00:00
DEBUG ( 5 , ( " The connection to the LDAP server was closed \n " ) ) ;
/* maybe free the results here --metze */
return NT_STATUS_OK ;
}
/* This function doesn't make as much sense in an LDAP world since the calling
node doesn ' t really control the ID ranges */
static void ldap_idmap_status ( void )
{
DEBUG ( 0 , ( " LDAP IDMAP Status not available \n " ) ) ;
}
static struct idmap_methods ldap_methods = {
ldap_idmap_init ,
2003-07-11 05:33:40 +00:00
ldap_allocate_rid ,
2003-07-09 16:44:47 +00:00
ldap_allocate_id ,
2003-06-03 18:19:59 +00:00
ldap_get_sid_from_id ,
ldap_get_id_from_sid ,
ldap_set_mapping ,
ldap_idmap_close ,
ldap_idmap_status
} ;
NTSTATUS idmap_ldap_init ( void )
{
return smb_register_idmap ( SMB_IDMAP_INTERFACE_VERSION , " ldap " , & ldap_methods ) ;
}
