Bug 3675 - winbind fails to get user group if user resides in DN with 'numero sign'
winbind fails to get user group if user resides in DN with 'numero sign'
Status: RESOLVED WONTFIX
Product: Samba 3.0
Classification: Unclassified
Component: winbind
3.0.22
x86 FreeBSD
: P3 normal
: none
Assigned To: Guenther Deschner
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-12 06:33 UTC by Denis Eremenko
Modified: 2007-02-28 12:00 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Denis Eremenko 2006-04-12 06:33:44 UTC
winbind fails to get user group if user resides not in "Users" OU.

[2006/04/12 16:13:01, 1, pid=91338, effective(0, 0), real(0, 0)] nsswitch/winbindd_ads.c:lookup_usergroups(651)
  lookup_usergroups(sid=S-1-5-21-1417001333-1960408961-682003330-1598) ads_search tokenGroups: NULL msg

tokenGroups IS in ADS schema!

But it doesn't retrieved with ldapsearch even.

% ldapsearch -W -x -D moonshade@pnhz.kz tokenGroups
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <> with scope sub
# filter: (objectclass=*)
# requesting: tokenGroups
#

# search result
search: 2
result: 1 Operations error
text: 00002120: SvcErr: DSID-03140183, problem 5012 (DIR_ERROR), data 0


# numResponses: 1


If user in "Users" OU - everything works fine.
Comment 1 Guenther Deschner 2006-04-12 06:44:09 UTC
An LDAP query (e.g. using ldapsearch) for tokenGroups only works when using the base scope (and setting the base to the accounts dn).
Comment 2 Denis Eremenko 2006-04-13 01:17:20 UTC
I have found the cause. This behaviour appears if DN have 'numero sign' (UTF-8: 0xE2 0x84 0x96). Without 'numero sign' everything works fine. Is this OpenLDAP issue?

But when object retrieved with ldapsearch and -t option (saving non-printable values to a set of temporary files) - i have the right utf-8 representation of 'numero sign' in temporary files (0xE2 0x84 0x96).

What can be done except removing evil symbol from directory?
Comment 3 Gerald (Jerry) Carter 2006-04-20 08:03:41 UTC
severity should be determined by the developers and not the reporter.
Comment 4 Guenther Deschner 2006-04-21 09:18:54 UTC
(In reply to comment #2)
> I have found the cause. This behaviour appears if DN have 'numero sign' (UTF-8:
> 0xE2 0x84 0x96). Without 'numero sign' everything works fine. Is this OpenLDAP
> issue?

No, we're pushing the incoming dn (which is already in utf8) to utf8 again and then fail to work with that dn as the basedn.

> What can be done except removing evil symbol from directory?

We need to fix that. I'll look into it the next days.
Comment 5 Guenther Deschner 2006-04-21 10:07:26 UTC
Just double checked, we're doing the correct conversion (I was wrong). And I could create a user with such characters in his dn without problems. 

Could you please post your locale settings and the charset settings from smb.conf (testparm -v -s | grep -i charset) ?
Comment 6 Guenther Deschner 2006-04-21 10:45:03 UTC
Is this windows 2000 ? If yes, what service pack?
Comment 7 Denis Eremenko 2006-04-23 22:17:49 UTC
(In reply to comment #5)
> Just double checked, we're doing the correct conversion (I was wrong). And I
> could create a user with such characters in his dn without problems. 
I suppose something wrong with koi8-r charset. KOI8-R have no 'numero sign' and it is lost on utf-8 to koi8-r conversion with libiconv.
But if so - is it normal? Directory uses utf-8 - is conversion to koi8-r and back justified?

> Could you please post your locale settings and the charset settings from
> smb.conf (testparm -v -s | grep -i charset) ?
dos charset = 866
unix charset = KOI8-R
display charset = KOI8-R
Comment 8 Denis Eremenko 2006-04-23 22:19:02 UTC
> Is this windows 2000 ? If yes, what service pack?
2000, sp4
Comment 9 Simo Sorce 2007-02-28 12:00:05 UTC
I think the only possible answer to this bug, right now, is to either make sure that you don't have KOI8-R incompatible characters in DNs on your directory or to switch to unix charset = utf8

Simo.