samba - Feb 2013 - "Samba 4" - "smbd"; "can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL" error but only for a single domain user ("Server 2008 R2" domain, "Server 2008" functional level forest).

Hello,

 

We're having a problem with "Samba 4" joined to a "Server
2008 R2" domain
(at "Server 2008" functional level across the forest).

The interesting thing is that this only affects a single user - all other
accounts work without problems.

 

When accessing our main server using that account, "smbd" always
reports
"can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL".  This has come
from
"../auth/kerberos/kerberos_pac.c:149(kerberos_decode_pac)", trying to
use
NDR to pull a blob from the Kerberos ticket (that's reported as
"ndr_pull_error(11): Pull bytes 34 
(../librpc/ndr/ndr_string.c:591)").

 

I can't see any reason for the error affecting this one specific user.

As the Kerberos PAC is mainly concerned with information such as
supplemental groups, I've altered the group membership for the user. 
I've
removed the user from all groups.  I've even completely deleted and
re-created the user (so a different SID, in case there was any corrupted
cached information anywhere).  Nothing makes any difference - that one user
consistently gets this error, and no others do.  I've even tried changing
the Kerberos encryption types in case that had any effect (was it the result
of a decryption problem?) but again, no difference.

It's not a client problem either, as I've tried accessing the Samba
shares
from various different platforms (even including an embedded Linux based
network media player - "Dune HD Max" - I happened to have on the
network) -
everything attempting to access as that user causes exactly the same
problem.

 

As this is happening in a call to the "NDR_PULL_NEED_BYTES()" macro, I
modified that slightly to print out a bit more information.  That resulted
in "ndr_pull_error(11): Pull bytes 34, data_size=88, offset=58,
unlikely(34)=1 (../librpc/ndr/ndr_string.c:591)", so it's quite right -
pulling 34 bytes from 88 of data at an offset of 58 will exceed the size of
the contents in the data buffer.

 

So the question is either why is it trying to pull 34 bytes from offset 58
of 88 data bytes (is that number 34 correct or has that been mis-decoded?),
why is the existing offset 58 (has something caused this to be set too far
into the data buffer already?) or why is the data size 88 bytes (has this
been decoded incorrectly somehow and should there be more?).

 

At this point, my knowledge of the internals of Samba and Kerberos stopped
me and I felt I had to ask people who know somewhat more than me - that
would be the readers of this list!

 

Incidentally, this used to work.

We've been running "Samba 4" for quite a while; we're not
using its' AD
server facilities, but found it considerably easier to get the version 4
codebase to compile up and run on this server (running "OpenSolaris")
- the
version 3 codebase gets very fiddly to persuade to work with the
"OpenSolaris" LDAP and Kerberos whereas the version 4 correctly
figures it
all out for itself very nicely thank you .

We also periodically update the code as we have (since first moving to
version 4) experienced occasional core-dumps.  They don't cause a major
problem, they're just a minor inconvenience, but it would be nice to lose
that inconvenience and I trust the Samba developers to have beta code that's
vastly more stable than most vendor's release code, so I don't mind
periodically updating the code straight from the current source snapshot
(via "git").

This user used not to have any problems, then about (from memory) 3 months
ago a code update caused this problem.  Unfortunately I don't know the
precise version numbers at which it was working and at which it broke - pity
as that would doubtless make it considerably easier to work out what might
have caused the problem :-(.

In poking around with "Google", I did find a single reference to a
change in
which the submitter said they had found exactly this error, again on just a
single account, but unfortunately I can't locate the post again (despite
searching my "Chrome" history).  As I recall, the code change was
committed
anyway as it was just a single account which had experienced the problem and
the change author didn't consider it to be significant.

 

There's obviously a whole lot more information I could attach;
"smb.conf"
file, full debug traces, the fact that "wbinfo -u"/"wbinfo
-g" etc. all work
correctly, . but there didn't seem any point attaching any of that unless it
would actually be useful.

What might be useful info. is that "smbd -V" reports "Version
4.1.0pre1-GIT-3e5acc1"; "testparm" is happy, as is "net ads
testjoin" (and
"net rpc testjoin", for that matter).

 

I'm not at all averse to going into the source code and adding debug code to
dig this problem out - with over 30 years 'C' experience (including
working
as a kernel/system developer on "mainstream" Unix) I'm quite happy
to dive
in and add code to the source tree, if that would contribute any useful
information.

 

So can anyone suggest any way forward to resolve this please?  It would
appear that something is incorrectly being decoded somewhere, so it's
probably to everyone's advantage to get this sorted out - I know it would
certainly be to mine :-)

 

Many thanks, and regards,

 

Tris Mabbs.

Hi

You might try getting a packet capture.

By the way, what's common between the user before you deleted the
account and the one you created later, besides the username?  The
password?  Can you replicate this in a test environment?

If you can replicate this in a test environment and you know more or
less when the problem started, perhaps you could use git bisect to
find exactly when it happened.

e.g. roll back samba to a version from 3 months ago.  If it works
there, tell git bisect that that is the last good version you know of.
 Then tell it that your current version is bad and let it choose the
versions for you to compile and test.  You keep telling it that the
version you've just tested is either good or bad and it will
eventually tell you which commit broke it.

Then you can post that information to the list.  (I suspect
samba-technical would be a better list for this sort of thing.)

Also, I'm pretty sure Samba should never core dump, so you might want
to post stack traces etc. when that happens.

On 25 February 2013 13:51, Tris Mabbs <TM-Samba201302 at firstgrade.co.uk>
wrote:
> Hello,
>
>
>
> We're having a problem with "Samba 4" joined to a
"Server 2008 R2" domain
> (at "Server 2008" functional level across the forest).
>
> The interesting thing is that this only affects a single user - all other
> accounts work without problems.
>
>
>
> When accessing our main server using that account, "smbd" always
reports
> "can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL".  This has
come from
> "../auth/kerberos/kerberos_pac.c:149(kerberos_decode_pac)",
trying to use
> NDR to pull a blob from the Kerberos ticket (that's reported as
> "ndr_pull_error(11): Pull bytes 34 
(../librpc/ndr/ndr_string.c:591)").
>
>
>
> I can't see any reason for the error affecting this one specific user.
>
> As the Kerberos PAC is mainly concerned with information such as
> supplemental groups, I've altered the group membership for the user. 
I've
> removed the user from all groups.  I've even completely deleted and
> re-created the user (so a different SID, in case there was any corrupted
> cached information anywhere).  Nothing makes any difference - that one user
> consistently gets this error, and no others do.  I've even tried
changing
> the Kerberos encryption types in case that had any effect (was it the
result
> of a decryption problem?) but again, no difference.
>
> It's not a client problem either, as I've tried accessing the Samba
shares
> from various different platforms (even including an embedded Linux based
> network media player - "Dune HD Max" - I happened to have on the
network) -
> everything attempting to access as that user causes exactly the same
> problem.
>
>
>
> As this is happening in a call to the "NDR_PULL_NEED_BYTES()"
macro, I
> modified that slightly to print out a bit more information.  That resulted
> in "ndr_pull_error(11): Pull bytes 34, data_size=88, offset=58,
> unlikely(34)=1 (../librpc/ndr/ndr_string.c:591)", so it's quite
right -
> pulling 34 bytes from 88 of data at an offset of 58 will exceed the size of
> the contents in the data buffer.
>
>
>
> So the question is either why is it trying to pull 34 bytes from offset 58
> of 88 data bytes (is that number 34 correct or has that been mis-decoded?),
> why is the existing offset 58 (has something caused this to be set too far
> into the data buffer already?) or why is the data size 88 bytes (has this
> been decoded incorrectly somehow and should there be more?).
>
>
>
> At this point, my knowledge of the internals of Samba and Kerberos stopped
> me and I felt I had to ask people who know somewhat more than me - that
> would be the readers of this list!
>
>
>
> Incidentally, this used to work.
>
> We've been running "Samba 4" for quite a while; we're not
using its' AD
> server facilities, but found it considerably easier to get the version 4
> codebase to compile up and run on this server (running
"OpenSolaris") - the
> version 3 codebase gets very fiddly to persuade to work with the
> "OpenSolaris" LDAP and Kerberos whereas the version 4 correctly
figures it
> all out for itself very nicely thank you .
>
> We also periodically update the code as we have (since first moving to
> version 4) experienced occasional core-dumps.  They don't cause a major
> problem, they're just a minor inconvenience, but it would be nice to
lose
> that inconvenience and I trust the Samba developers to have beta code
that's
> vastly more stable than most vendor's release code, so I don't mind
> periodically updating the code straight from the current source snapshot
> (via "git").
>
> This user used not to have any problems, then about (from memory) 3 months
> ago a code update caused this problem.  Unfortunately I don't know the
> precise version numbers at which it was working and at which it broke -
pity
> as that would doubtless make it considerably easier to work out what might
> have caused the problem :-(.
>
> In poking around with "Google", I did find a single reference to
a change in
> which the submitter said they had found exactly this error, again on just a
> single account, but unfortunately I can't locate the post again
(despite
> searching my "Chrome" history).  As I recall, the code change was
committed
> anyway as it was just a single account which had experienced the problem
and
> the change author didn't consider it to be significant.
>
>
>
> There's obviously a whole lot more information I could attach;
"smb.conf"
> file, full debug traces, the fact that "wbinfo -u"/"wbinfo
-g" etc. all work
> correctly, . but there didn't seem any point attaching any of that
unless it
> would actually be useful.
>
> What might be useful info. is that "smbd -V" reports
"Version
> 4.1.0pre1-GIT-3e5acc1"; "testparm" is happy, as is "net
ads testjoin" (and
> "net rpc testjoin", for that matter).
>
>
>
> I'm not at all averse to going into the source code and adding debug
code to
> dig this problem out - with over 30 years 'C' experience (including
working
> as a kernel/system developer on "mainstream" Unix) I'm quite
happy to dive
> in and add code to the source tree, if that would contribute any useful
> information.
>
>
>
> So can anyone suggest any way forward to resolve this please?  It would
> appear that something is incorrectly being decoded somewhere, so it's
> probably to everyone's advantage to get this sorted out - I know it
would
> certainly be to mine :-)
>
>
>
> Many thanks, and regards,
>
>
>
> Tris Mabbs.
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba


-- 
Michael Wood <esiotrot at gmail.com>

Hiya Michael,

 

Many thanks for the quick and helpful response.

 

Yes, I can certainly try a packet capture; I think I'll go with your other
suggestion first though, that of using "git bisect" to track down the
problematic version.

I'm sorry, that should have occurred to me .

Once I've identified the problematic version, I can post that information
and then start capturing packets if necessary.  Who knows - finding where
the break occurred might make someone such as yourself slap your forehead in
a Homer Simpson like way ("Doh!") and say "Of *course*,
that's what will
have done it ." :-).

 

It's not in a test environment; we don't run one here (the development
work
we do doesn't require a separate test network), so this is on our production
network.  However I have considerable freedom in taking servers out of
service so long as it's not during the most active times, so I'm quite
happy
to bounce versions around (and perform any other tests required).

 

As for what was common between the original and the re-created user - the
username.  That's it.  I didn't even bother setting up the description
information.   However I also tried renaming the account and the problem
still occurred, so I'm not at all sure exactly what is causing it.

I did originally set the password to be the same, but have since reset it
several times (to varying lengths; I know that shouldn't affect this sort of
problem but by then I was running out of ideas .).

 

You're also quite correct in that Samba shouldn't core dump.  However I
think I'll get to the bottom of this problem and then perhaps start a
separate thread on that, rather than obfuscating this one with multiple
problems.  So thanks for the thought - I'll raise a new problem for that
once this has been sorted.

 

I can't take that server down just at the moment - middle of the working day
here.  However I'll see whether I can switch versions around until I can
find the problem hopefully later on this-evening.

 

Once again, many thanks for the most helpful suggestions.  Watch this space
for the responses.

 

Tris.

On Mon, 2013-02-25 at 11:51 +0000, Tris Mabbs wrote:
> Hello,
> 
>  
> 
> We're having a problem with "Samba 4" joined to a
"Server 2008 R2" domain
> (at "Server 2008" functional level across the forest).
> 
> The interesting thing is that this only affects a single user - all other
> accounts work without problems.
> 
>  
> 
> When accessing our main server using that account, "smbd" always
reports
> "can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL".  This has
come from
> "../auth/kerberos/kerberos_pac.c:149(kerberos_decode_pac)",
trying to use
> NDR to pull a blob from the Kerberos ticket (that's reported as
> "ndr_pull_error(11): Pull bytes 34 
(../librpc/ndr/ndr_string.c:591)").
> 
>  
> So can anyone suggest any way forward to resolve this please?  It would
> appear that something is incorrectly being decoded somewhere, so it's
> probably to everyone's advantage to get this sorted out - I know it
would
> certainly be to mine :-)
'Clearly' (as in, clear as mud, but the general direction to look at)
either the IDL in librpc/idl/krb5pac.idl is incorrect, or the parsing code in
Heimdal in unpacking this particular user's PAC incorrectly.

It is interesting that this user causes the issue regardless of being
re-created.  Is this triggered on their full or user name?

Does this happen if you set up a new testing domain?  If so, what would
be really, really helpful would be a network capture including the
server keytab.  (Or if you don't mind, and change the server password
after, on your live domain to me personally).

The procedure you or I will need to follow is to extract the decrypted
'PAC'.  You could do this either from wireshark (export selected packet
bytes, after running wireshark -k /tmp/server.keytab, or by patching the
code to call:

_PUBLIC_ bool file_save(const char *fname, const void *packet, size_t
length)

somewhere near auth3_generate_session_info_pac()

Then, using that file, run 

bin/ndrdump krb5pac decode_pac in /tmp/pac

Then essentially we keep changing the idl in librpc/idl/krb5pac.idl and
the C helpers in librpc/ndr/ndr_krb5pac.c until this works.

See also http://msdn.microsoft.com/en-us/library/cc237917.aspx

Good luck!

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org

Hi Triss,

can you test this branch?

https://git.samba.org/?p=gd/samba/.git;a=shortlog;h=refs/heads/master-krb5pac

It contains fixes for various pac buffer types.

Let us know if it resolves your issues.

Thanks,
Guenther


-- 
G?nther Deschner                    GPG-ID: 8EE11688
Red Hat                         gdeschner at redhat.com
Samba Team                              gd at samba.org

Good day, one and all ...

I just had to rebuild our main Samba server ("OpenSlowlaris" ->
"Slowlaris 11.11"), during which I put the latest (at the time;
currently 4.2.0pre1-GIT-b505111) Samba4 on there.  I thought that by now that
Gunther's speculative changes to improve the PAC decode might have made
their way into the trunk revision - obviously I was wrong, as I'm once again
getting a load of "Can't parse the PAC:
NT_STATUS_BUFFER_TOO_SMALL" messages and a user who can't access any
Samba shares.

Whoops ...

So as we previously discussed looking into things in more detail (specifically
finding out why there is no "client_principal" being passed into
"kerberos_decode_pac()"), but nothing else ever happened, is there
anything I can do to assist in getting the improved PAC decoding included into
the trunk revision?  Whilst I can't guarantee immediate responses to any
request, I'm quite happy to stick any code in anywhere you might want if you
don't mind potentially waiting a day or so for the results :-)

Also:
I appreciate this is off-topic, but I was wondering whether anyone is interested
in/would like me to open a separate thread on any of these ...
Built the code, installed the code, set it up (joined the domain, etc. etc. etc.
etc.).  Had 2(-and-a-bit) problems (one of which I've fixed):
	1. Although "bin/default/source3/winbindd/idmap_ad_4.o" gets built,
"bin/default/source3/winbindd/libidmap-ad.so" doesn't, so
"<TARGDIR>/lib/idmap/ad.so" doesn't get installed.  No
"ad" idmap backend; no AD UID/SID mapping; much administrator (me)
confusion if said administrator is expecting AD UID/SID mapping to work ...
	  I'd completely forgotten about this little "hiccup" - it's
been a while since I initially shoe-horned Samba4 onto
"OpenSlowlaris", but fortunately I'd made a note of this in the
build script I used so after 2 days of banging my head against a wall, I finally
remembered to check my own darn' script and saw the comment "If
''/usr/local/samba/lib/idmap/ad.so'' doesn't build and
install then ...".  Bang bang bang bang ...  Doh!
	   Linked "libidmap-ad.so" manually and copied into
"/usr/local/samba/lib/idmap/ad.so" and, as if by magic, my UID/SID
mapping started working ...
	2. "net ads testjoin" works; "wbinfo -t" works (as do
"wbinfo -u", "wbinfo -g", ....).  In fact everything works
(after installing "ad.so"!) *except* ...  If I do a "net rpc
testjoin" (and remember, "wbinfo -t" *does* work here) I get an
error stating that it can't connect to "GATEWAY" (local server
name) and therefore the join to the "FIRSTGRADE" domain isn't
valid.
	   Duh?
	   So for some reason, "net rpc testjoin" is trying to connect to the
local server rather than any DC for the domain.  No particular reason apparent
in the log files, and it doesn't seem to be affecting anything, but it is an
odd disparity.  Ramped up debugging but couldn't see any sensible
explanation in the logs ...
	[3. Kinda ...  Sorta ...  Can't build Samba4 on "Slowlaris 11.11"
without complaints about "no ldap_add_result_entry() support in LDAP
libs!" filling every log file on the system.
	    So I kicked and forced and prodded and poked and finally managed to
persuade Samba to build using OpenLDAP-2.4, which gets rid of this problem.
	    However that involved fiddling with "CPPFLAGS" and
"LDFLAGS" before calling any build scripts; it's nasty, messy and
dirty - I don't approve of any "solution" which involves that sort
of messing around (yuk).  There has to be a better way ...
	    From looking at other discussions, it seems Samba4 as a DC isn't
supported (yet?) using OpenLDAP, but might it be worthwhile providing some way
to "encourage" the use of OpenLDAP, rather than the OS native LDAP
(whatever that may be), if it *can* be used?  Perhaps a
"--I-cant-believe-its-not-OpenLDAP" flag of some sort (sorry, British
humour - that probably doesn't mean anything to anyone else ...)?]
If you think it's worth opening a thread on any of these (probably, I'd
guess, in the main Samba discussion rather than Samba-Technical?) then please
say so and I'll do so.  Otherwise I'll continue quietly to ignore them
:-)

Many thanks folks, and have a great week/weekend,

Cheers,

Tris.

-----Original Message-----
From: Tris Mabbs [mailto:TM-Samba201302 at Firstgrade.Co.UK] 
Sent: 15 March 2013 17:59
To: Andrew Bartlett
Cc: 'Michael Wood'; Guenther Deschner; samba at lists.samba.org;
samba-technical at samba.org
Subject: RE: [Samba] "Samba 4" - "smbd"; "can't
parse the PAC: NT_STATUS_BUFFER_TOO_SMALL" error but only for a single
domain user ("Server 2008 R2" domain, "Server 2008"
functional level forest).
>> 	So it seems that with these changes, "kerberos_decode_pac()"
is
>> never entered with "client_principal" anything other than a
NULL pointer.
>> 
>> So I'm (very) happy that these changes fix my problem.  However it 
>> does seem a little curious that "client_principal" now never
appears
>> to be set - I don't know whether that's expected behaviour?
>
> It isn't, we need to look into that some more. 
	More than happy to - let me know what you want put where and it'll be done.

	Meanwhile, having cleared them out recently, I currently have ~3,600 PAC dumps,
not a single one with the Kerberos principal in the name (every one's a PID
based name).

	On the plus side, still nary a core dump:

------->Cut here:
# find /var/samba4/log/cores/ -type f
#
<-------Cut here.
> Does the ndrdump run you did before now pass fine?
	Yes, runs perfectly:

------->Cut here:
% /var/tmp/samba/samba-master/samba-gd/bin/ndrdump krb5pacdecode_pac in
PAC-NDR-1819 pull returned NT_STATUS_OK
    decode_pac: struct decode_pac
        in: struct decode_pac
            pac: struct PAC_DATA
                num_buffers              : 0x00000005 (5)
                version                  : 0x00000000 (0)
                buffers: ARRAY(5)
                    buffers: struct PAC_BUFFER
                        type                     : PAC_TYPE_LOGON_INFO (1)
                        _ndr_size                : 0x00000248 (584)
                        info                     : *
                            info                     : union PAC_INFO(case 1)
                            logon_info: struct PAC_LOGON_INFO_CTR

...

                    buffers: struct PAC_BUFFER
                        type                     : PAC_TYPE_KDC_CHECKSUM (7)
                        _ndr_size                : 0x00000014 (20)
                        info                     : *
                            info                     : union PAC_INFO(case 7)
                            kdc_cksum: struct PAC_SIGNATURE_DATA
                                type                     : KERB_CHECKSUM_HMAC_MD
5 (0xFFFFFF76)
                                signature                : DATA_BLOB length=16
[0000] 3B 96 CC BB BB 9D E4 57   13 C9 6D 1C 65 A0 B1 1B   ;......W ..m.e...
                                RODCIdentifier           : 0x0000 (0)
                        _pad                     : 0x00000000 (0)
dump OK
%
<------- Cut here.

Large amounts of data, all looking absolutely fine.

So definite progress ...

Many thanks, regards, and have a great weekend everyone,

Tris.

Well, since I have no answer from Debian in order of patch, I'm trying
to do the import using group names with no special character at all.

Strange thing - it dosen't work.
I have also removed all diacritics from displayname attributes for all
groups - dosen't help either.

So i'm not sure, what the problem really is.

Dňa 24.09.2015 o 13:52 Mgr. Peter Tuharsky napísal(a):
> As of 4, I have tested import of renamed domain and the classicupdate is
> still parsing badly. So the netbios name seems not to be an issue for now.
>
> Dňa 24.09.2015 o 10:45 Mgr. Peter Tuharsky napísal(a):
>> Hi all,
>>
>> thank You for Your answers and the help.
>>
>> 1, I have never applied a patch to Samba in Debian. Please, is there
any
>> howto or documentation?
>> 2, If the patch worked for the import, would it be possible to revert
to
>> a distributional (unpatched) Samba afterwards?
>> 3, We don't use any of the mentioned symbols in group names, just .
and -
>> 4, Unfortunately, we have a . in the NT4 (netbios) domain name. We
>> already have issues with that, but only in Windows 8. Could this be the
>> reason of the import error? I doubt that though because other import
>> steps finished flawlessly, including netbios name registration during
>> import process.
>> 5, (Might be OT, depending on previous answer): If needed in order to
>> resolve the problem, is it possible to simply and without consequences
>> change the domain (netbios) name in LDAP, providing that SID would
>> remain untouched and change in smb.conf would reflect the new name? Or
>> the Windows clients use both the netbios name and SID in order to
access
>> their domain and they would drop off domain?
>>
>> Peter
>>
>> Dňa 24.09.2015 o 09:57 Andrew Bartlett napísal(a):
>>> On Thu, 2015-09-24 at 09:12 +0200, Michael Wood wrote:
>>>> Hi
>>>> On 23 Sep 2015 9:47 PM, "Andrew Bartlett"
<abartlet at samba.org> wrote:
>>>>> On Thu, 2015-09-24 at 06:59 +1200, Andrew Bartlett wrote:
>>>>>> That looks like a bug.  My guess is that, as Roland
suggested,
>>>> the
>>>>>> group name isn't just normal characters.  We do
support other
>>>> chars
>>>>>> in
>>>>>> group names, but the bug here was not to escape the
values.  You
>>>>>> could
>>>>>> expect a particular problem with any of these in
particular: =,()
>>>>> Can you confirm this patch (against master, but should
apply back
>>>> to
>>>>> 4.1) works for you?
>>>>>
>>>>> If so, can I get a second team member to review/push?
>>>> Does that still result in them being in CN=Users? Or is that
not
>>>> important?
>>> Indeed, that is what I get for writing patches at 7 in the morning
:-)
>>>
>>> Try the attached.  We really, really need some good expected-value
>>> testing of the upgrade system.
>>>
>>> Thanks,
>>>
>>> Andrew Bartlett
>>>
>

I have tested the patch against 4.3.1 compiled from sources but it does
not seem to work. Either I did something wrong while compiling, or the
patch dosen't fix the problem.

ERROR(<type 'exceptions.ValueError'>): uncaught exception - unable
to
parse dn string
  File
"/usr/local/samba/lib/python2.7/site-packages/samba/netcmd/__init__.py",
line 175, in _run
    return self.run(*args, **kwargs)
  File
"/usr/local/samba/lib/python2.7/site-packages/samba/netcmd/domain.py",
line 1460, in run
    useeadb=eadb, dns_backend=dns_backend, use_ntvfs=use_ntvfs)
  File
"/usr/local/samba/lib/python2.7/site-packages/samba/upgrade.py",
line 771, in upgrade_from_samba3
    add_group_from_mapping_entry(result.samdb, g, logger)
  File
"/usr/local/samba/lib/python2.7/site-packages/samba/upgrade.py",
line 275, in add_group_from_mapping_entry
    m.dn = ldb.Dn(samdb, "CN=%s,CN=Users,%s" % (groupmap.nt_name,
samdb.get_default_basedn()))

Dňa 08.10.2015 o 08:47 Mgr. Peter Tuharsky napísal(a):
> Well, since I have no answer from Debian in order of patch, I'm trying
> to do the import using group names with no special character at all.
>
> Strange thing - it dosen't work.
> I have also removed all diacritics from displayname attributes for all
> groups - dosen't help either.
>
> So i'm not sure, what the problem really is.
>
> Dňa 24.09.2015 o 13:52 Mgr. Peter Tuharsky napísal(a):
>> As of 4, I have tested import of renamed domain and the classicupdate
is
>> still parsing badly. So the netbios name seems not to be an issue for
now.
>>
>> Dňa 24.09.2015 o 10:45 Mgr. Peter Tuharsky napísal(a):
>>> Hi all,
>>>
>>> thank You for Your answers and the help.
>>>
>>> 1, I have never applied a patch to Samba in Debian. Please, is
there any
>>> howto or documentation?
>>> 2, If the patch worked for the import, would it be possible to
revert to
>>> a distributional (unpatched) Samba afterwards?
>>> 3, We don't use any of the mentioned symbols in group names,
just . and -
>>> 4, Unfortunately, we have a . in the NT4 (netbios) domain name. We
>>> already have issues with that, but only in Windows 8. Could this be
the
>>> reason of the import error? I doubt that though because other
import
>>> steps finished flawlessly, including netbios name registration
during
>>> import process.
>>> 5, (Might be OT, depending on previous answer): If needed in order
to
>>> resolve the problem, is it possible to simply and without
consequences
>>> change the domain (netbios) name in LDAP, providing that SID would
>>> remain untouched and change in smb.conf would reflect the new name?
Or
>>> the Windows clients use both the netbios name and SID in order to
access
>>> their domain and they would drop off domain?
>>>
>>> Peter
>>>
>>> Dňa 24.09.2015 o 09:57 Andrew Bartlett napísal(a):
>>>> On Thu, 2015-09-24 at 09:12 +0200, Michael Wood wrote:
>>>>> Hi
>>>>> On 23 Sep 2015 9:47 PM, "Andrew Bartlett"
<abartlet at samba.org> wrote:
>>>>>> On Thu, 2015-09-24 at 06:59 +1200, Andrew Bartlett
wrote:
>>>>>>> That looks like a bug.  My guess is that, as Roland
suggested,
>>>>> the
>>>>>>> group name isn't just normal characters.  We do
support other
>>>>> chars
>>>>>>> in
>>>>>>> group names, but the bug here was not to escape the
values.  You
>>>>>>> could
>>>>>>> expect a particular problem with any of these in
particular: =,()
>>>>>> Can you confirm this patch (against master, but should
apply back
>>>>> to
>>>>>> 4.1) works for you?
>>>>>>
>>>>>> If so, can I get a second team member to review/push?
>>>>> Does that still result in them being in CN=Users? Or is
that not
>>>>> important?
>>>> Indeed, that is what I get for writing patches at 7 in the
morning :-)
>>>>
>>>> Try the attached.  We really, really need some good
expected-value
>>>> testing of the upgrade system.
>>>>
>>>> Thanks,
>>>>
>>>> Andrew Bartlett
>>>>
>