Are you attempting to perform AD authentication using a Samba domain
member server configuration and experiencing problems regarding the
UID2SID due to the CN attribute not being RFC2307 compliant?
Example in logs and examples of performing account look ups:
%> wbinfo -n USERNAME
S-1-5-21-2868754479-89028146-2101856903-111473 User (1)
%> wbinfo -i USERNAME
Could not get info for user USERNAME
%> wbinfo -S S-1-5-21-2868754479-89028146-2101856903-111473 User (1)
Could not convert sid S-1-5-21-2868754479-89028146-2101856903-111473 to uid
%> wbinfo -S S-1-5-21-2868754479-89028146-2101856903-111473 User (1)
*/var/log/samba/log.winbindd*
[2008/05/28 09:50:04, 10]
nsswitch/winbindd_cache.c:cache_retrieve_response(2300)
Retrieving response for pid 24973
[2008/05/28 09:50:04, 5] nsswitch/winbindd_async.c:winbindd_sid2uid_recv(347)
sid2uid returned an error
Could not convert sid S-1-5-21-2868754479-89028146-2101856903-111473 to gid
*/var/log/samba/log.winbindd-idmap*
[2008/05/28 09:50:51, 10] nsswitch/winbindd_dual.c:child_process_request(479)
process_request: request fn DUAL_SID2UID
[2008/05/28 09:50:51, 3] nsswitch/winbindd_async.c:winbindd_dual_sid2uid(374)
[24634]: sid to uid S-1-5-21-2868754479-89028146-2101856903-111473
[2008/05/28 09:50:51, 10] nsswitch/idmap_util.c:idmap_sid_to_uid(105)
idmap_sid_to_uid: sid = [S-1-5-21-2868754479-89028146-2101856903-111473]
[2008/05/28 09:50:51, 10] nsswitch/idmap_util.c:idmap_sid_to_uid(125)
sid [S-1-5-21-2868754479-89028146-2101856903-111473] not mapped to an uid
[2,1,2213796440]
If this is the problem you are experiencing I have a perl script that
requires the ldapsearch and ldapmodify tools which performs a check on
each account within an OU and creates a .ldif file with the modified DN
attribute which fixes this issue.
Let me know.
[email protected] wrote:
I seriously doubt that this can be done; however, I thought I might as
well ask anyway.
Is it possible to set one attribute equal to another one.
EXAMPLE:
Let say cn=Example Client
Is there anyway to make something like "displayName" equal to the "cn"
setting without having to physically enter the actual information?
If the thrust of this is to make sure that SOMETHING gets displayed,
surely that is something that the client, looking to display the
"displayName" attribute, would be controlling, rather than ferkeling
the server.
The client would get both and if it finds the "displayName" atrribute
is not set, just use the "cn" where it wanted the former.
If all you want to do is maintain a consistency across the DIT then
any (scripting) language that has an LDAP binding that allows one to
query and set attributes in the objects would achieve what you want
here - automated data entry.
Of course, if you are trying to prevent users from modifying the
"displayName" and force it be the "cn", then that's an attribute
access issue.
--
Jason Gerfen
Systems Administration/Web application development
[email protected]
Marriott Library
Lab Systems PC
295 South 1500 East
Salt Lake City, Utah 84112-0806
Ext 5-9810
