Re: [Samba] AD DC eventually not browsable without restart

[Kevin Field]

(Just for the record, I haven't restarted samba in a couple weeks now.)

That's very interesting: via the IP, it is browsable.

As for the outputs:

$ sudo netstat -anp | grep "samba\|smb"
tcp0  0 0.0.0.0:139 0.0.0.0:* 
LISTEN  5714/samba
tcp0  0 0.0.0.0:464 0.0.0.0:* 
LISTEN  19028/samba
tcp0  0 0.0.0.0:53  0.0.0.0:* 
LISTEN  19035/samba
tcp0  0 0.0.0.0:88  0.0.0.0:* 
LISTEN  19028/samba
tcp0  0 0.0.0.0:636 0.0.0.0:* 
LISTEN  19026/samba
tcp0  0 0.0.0.0:445 0.0.0.0:* 
LISTEN  19034/samba
tcp0  0 0.0.0.0:10240.0.0.0:* 
LISTEN  19023/samba
tcp0  0 0.0.0.0:32680.0.0.0:* 
LISTEN  19026/samba
tcp0  0 0.0.0.0:32690.0.0.0:* 
LISTEN  19026/samba
tcp0  0 0.0.0.0:389 0.0.0.0:* 
LISTEN  19026/samba
tcp0  0 0.0.0.0:135 0.0.0.0:* 
LISTEN  19023/samba
tcp0  0 10.0.1.2:44510.0.1.1:1777 
ESTABLISHED 19044/samba
tcp0  0 10.0.1.2:1024   10.0.1.1:3024 
ESTABLISHED 19023/samba
tcp0  0 10.0.1.2:44510.0.1.1:2130 
ESTABLISHED 5714/samba
tcp0  0 10.0.1.2:58561  10.0.1.1:1025 
ESTABLISHED 19029/samba
udp0  0 10.0.1.2:3890.0.0.0:* 
19027/samba
udp0  0 0.0.0.0:389 0.0.0.0:* 
19027/samba
udp0  0 10.0.1.2:1370.0.0.0:* 
19024/samba
udp0  0 10.255.255.255:137  0.0.0.0:* 
19024/samba
udp0  0 0.0.0.0:137 0.0.0.0:* 
19024/samba
udp0  0 10.0.1.2:1380.0.0.0:* 
19024/samba
udp0  0 10.255.255.255:138  0.0.0.0:* 
19024/samba
udp0  0 0.0.0.0:138 0.0.0.0:* 
19024/samba
udp0  0 0.0.0.0:53  0.0.0.0:* 
19035/samba
udp0  0 10.0.1.2:4640.0.0.0:* 
19028/samba
udp0  0 0.0.0.0:464 0.0.0.0:* 
19028/samba
udp0  0 10.0.1.2:88 0.0.0.0:* 
19028/samba
udp0  0 0.0.0.0:88  0.0.0.0:* 
19028/samba
unix  2  [ ] DGRAM1900834 5714/samba 
  /var/lib/samba/private/smbd.tmp/msg/msg.5714
unix  2  [ ACC ] STREAM LISTENING 413329 19023/samba 
 /var/run/samba/ncalrpc/np/dnsserver
unix  2  [ ACC ] STREAM LISTENING 413331 19023/samba 
 /var/run/samba/ncalrpc/np/ntsvcs
unix  2  [ ACC ] STREAM LISTENING 413334 19023/samba 
 /var/run/samba/ncalrpc/np/browser
unix  2  [ ACC ] STREAM LISTENING 413336 19023/samba 
 /var/run/samba/ncalrpc/np/unixinfo
unix  2  [ ACC ] STREAM LISTENING 413339 19023/samba 
 /var/run/samba/ncalrpc/np/protected_storage
unix  2  [ ACC ] STREAM LISTENING 413344 19023/samba 
 /var/run/samba/ncalrpc/np/spoolss
unix  2  [ ] DGRAM413345 19025/samba 
 /var/lib/samba/private/smbd.tmp/msg/msg.19025
unix  2  [ ACC ] STREAM LISTENING 413347 19023/samba 
 /var/run/samba/ncalrpc/np/lsass
unix  2  [ ACC ] STREAM LISTENING 413350 19023/samba 
 /var/run/samba/ncalrpc/np/lsarpc
unix  2  [ ACC ] STREAM LISTENING 413352 19023/samba 
 /var/run/samba/ncalrpc/np/netlogon
unix  2  [ ACC ] STREAM LISTENING 413354 19023/samba 
 /var/run/samba/ncalrpc/np/samr
unix  2  [ ACC ] STREAM LISTENING 413356 19023/samba 
 /var/run/samba/ncalrpc/np/rpcecho
unix  2  [ ACC ] STREAM LISTENING 413358 19023/samba 
 /var/run/samba/ncalrpc/DEFAULT
unix  2  [ ACC ] STREAM LISTENING 413363 19023/samba 
 /var/run/samba/ncalrpc/np/wkssvc
unix  2  [ ACC ] STREAM LISTENING 413404 19031/samba 
 /var/lib/samba/ntp_signd/socket
unix  2  [ ACC ] STREAM LISTENING 413365 19023/samba 
 /var/run/samba/ncalrpc/EPMAPPER
unix  2  [ ] DGRAM413367 19026/samba 
 /var/lib/samba/private/smbd.tmp/msg/msg.19026
unix  2  [ ACC ] STREAM LISTENING 413372 19023/samba 
 /var/run/samba/ncalrpc/np/epmapper
unix  2  [ ] DGRAM413374 19027/samba 
 /var/lib/samba/private/smbd.tmp/msg/msg.19027
unix  2  [ ] DGRAM413382 19028/samba 
 /var/lib/samba/private/smbd.tmp/msg/msg.19028
unix  2   

Re: [Samba] Conversion error: Illegal multibyte sequence

[Laurent Blume]

On 2013-09-05 11:34 PM, Jeremy Allison wrote:
> No, it doesn't make sense. smb_iconv() vectors
> through pull and push function pointers that
> do the actual conversion - that's where the
> errno is coming from. That's why you need
> debug statements - you know it's going into
> smb_iconv() but you don't know where it's
> going from there.
> 
> Jeremy.
> 

At least those proved that neither Solaris' nor GNU's iconv were
involved :-)

I tagged all the possibles causes for EILSEQ, so here's the code causing
that issue, in lib/util/charset/iconv.c:

if ((c[0] & 0xf0) == 0xe0) {
if (in_left < 3 ||
(c[1] & 0xc0) != 0x80 ||
(c[2] & 0xc0) != 0x80) {
errno = EILSEQ;
DEBUG(3,("DEBUG, %d, %d, %d, %d\n",
in_left, c[0], c[1], c[2]));
goto error;
}

It happens because in_left == 2 when it should be 3:

[2013/09/06 20:59:50.249004,  3] ../lib/util/charset/iconv.c:600(utf8_pull)
  DEBUG, 2, 226, 153, 187
[2013/09/06 20:59:50.249056,  3] lib/charcnv.c:161(convert_string_internal)
  convert_string_internal: Conversion error: Illegal multibyte
sequence(â<99>»_Corbeille)

The sequence values are good, as this char is 0xE2 0x99 0xBB in UTF8.

I tried to backtrack the origin of this value, but I got lost after
convert_string_internal() in source3/lib/charcnv.c , where it was
incorrect already.

Is it getting warmer?

Laurent
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Re: [Samba] samba Digest, Vol 129, Issue 7

[paulw]

I am Currently out of the office and will return on Monday 9th September.
My email will not be monitor , so if you require assistance please email 
supp...@swift-computing.co.uk.

-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Re: [Samba] AD DC eventually not browsable without restart

[Kevin Field]

Nothing too interesting:

$ sudo tail -n 50 /var/log/samba/log.smbd
  smbd version 4.0.8-SerNet-RedHat-4.el6 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2012
[2013/08/15 17:56:21.535409,  0] ../source3/smbd/server.c:1253(main)
  server role = 'active directory domain controller' not compatible 
with running smbd standalone.
  You should start 'samba' instead, and it will control starting smbd 
if required

[2013/08/15 22:57:15,  0] ../source3/smbd/server.c:1201(main)
  smbd version 4.0.8-SerNet-RedHat-4.el6 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2012
[2013/08/15 22:57:15,  0] ../source3/param/loadparm.c:3121(lp_do_parameter)
  Ignoring unknown parameter "dns recursive queries"
[2013/08/15 22:57:15.902304,  0] 
../source3/param/loadparm.c:3121(lp_do_parameter)

  Ignoring unknown parameter "dns recursive queries"
[2013/08/15 22:57:15.909854,  0] ../source3/smbd/server.c:1281(main)
  standard input is not a socket, assuming -D option
[2013/08/15 22:57:16.631301,  0] 
../source3/printing/print_cups.c:151(cups_connect)

  Unable to connect to CUPS server localhost:631 - Connection refused
[2013/08/15 22:57:16.632045,  0] 
../source3/printing/print_cups.c:528(cups_async_callback)

  failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL
[2013/08/15 22:58:16.689780,  0] 
../source3/printing/print_cups.c:151(cups_connect)

  Unable to connect to CUPS server localhost:631 - Connection refused
[2013/08/15 22:58:16.690368,  0] 
../source3/printing/print_cups.c:528(cups_async_callback)

  failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL
[2013/08/15 23:00:37.725980,  0] 
../source3/param/loadparm.c:3033(lp_set_enum_parm)
  WARNING: Ignoring invalid value 'unsecure' for parameter 'allow dns 
updates'
[2013/08/15 23:00:37.726249,  0] 
../source3/param/loadparm.c:3121(lp_do_parameter)

  Ignoring unknown parameter "dns recursive queries"
[2013/08/15 23:00:37.772626,  0] 
../source3/param/loadparm.c:3033(lp_set_enum_parm)
  WARNING: Ignoring invalid value 'unsecure' for parameter 'allow dns 
updates'
[2013/08/15 23:00:37.772883,  0] 
../source3/param/loadparm.c:3121(lp_do_parameter)

  Ignoring unknown parameter "dns recursive queries"
[2013/08/15 23:00:38.037790,  0] 
../source3/param/loadparm.c:3033(lp_set_enum_parm)
  WARNING: Ignoring invalid value 'unsecure' for parameter 'allow dns 
updates'
[2013/08/15 23:00:38.038080,  0] 
../source3/param/loadparm.c:3121(lp_do_parameter)

  Ignoring unknown parameter "dns recursive queries"
[2013/08/15 23:02:35.872174,  0] 
../source3/param/loadparm.c:3121(lp_do_parameter)

  Ignoring unknown parameter "dns recursive queries"
[2013/08/15 23:02:35.935461,  0] 
../source3/param/loadparm.c:3121(lp_do_parameter)

  Ignoring unknown parameter "dns recursive queries"
[2013/08/15 23:02:36.200408,  0] 
../source3/param/loadparm.c:3121(lp_do_parameter)

  Ignoring unknown parameter "dns recursive queries"
[2013/08/15 23:02:39.710286,  0] 
../source3/param/loadparm.c:3121(lp_do_parameter)

  Ignoring unknown parameter "dns recursive queries"
[2013/08/15 23:02:39.792444,  0] 
../source3/param/loadparm.c:3121(lp_do_parameter)

  Ignoring unknown parameter "dns recursive queries"
[2013/08/15 23:02:40.054341,  0] 
../source3/param/loadparm.c:3121(lp_do_parameter)

  Ignoring unknown parameter "dns recursive queries"
[2013/08/15 23:02:55.374983,  0] 
../source3/param/loadparm.c:3121(lp_do_parameter)

  Ignoring unknown parameter "dns recursive queries"
[2013/08/15 23:04:13.125656,  0] 
../source3/param/loadparm.c:3121(lp_do_parameter)

  Ignoring unknown parameter "dns recursive queries"


And:

top - 14:47:13 up 14 days, 22:05,  1 user,  load average: 0.13, 0.12, 0.09
Tasks: 222 total,   1 running, 221 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si, 
0.0%st

Mem:  12194316k total,  6204420k used,  5989896k free,   810524k buffers
Swap:  6168568k total, 2784k used,  6165784k free,  4471196k cached

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
1 root  20   0 19228 1364 1124 S  0.0  0.0   0:00.56 init
2 root  20   0 000 S  0.0  0.0   0:00.00 kthreadd
3 root  RT   0 000 S  0.0  0.0   0:00.27 migration/0
4 root  20   0 000 S  0.0  0.0   0:03.66 ksoftirqd/0
5 root  RT   0 000 S  0.0  0.0   0:00.00 migration/0
6 root  RT   0 000 S  0.0  0.0   0:00.57 watchdog/0
7 root  RT   0 000 S  0.0  0.0   0:00.42 migration/1
8 root  RT   0 000 S  0.0  0.0   0:00.00 migration/1
9 root  20   0 000 S  0.0  0.0   0:03.36 ksoftirqd/1
   10 root  RT   0 000 S  0.0  0.0   0:00.47 watchdog/1
   11 root  RT   0 000 S  0.0  0.0   0:00.38 migration/2
   12 root  RT   0 000 S  0.0  0.0   0:00.00 migration/2
   13 root  20   0 000 S  0.0  0.0   0:03.76 ksoftirqd/2
  

Re: [Samba] Conversion error: Illegal multibyte sequence

[Jeremy Allison]

On Fri, Sep 06, 2013 at 09:40:25PM +0200, Laurent Blume wrote:
> On 2013-09-05 11:34 PM, Jeremy Allison wrote:
> > No, it doesn't make sense. smb_iconv() vectors
> > through pull and push function pointers that
> > do the actual conversion - that's where the
> > errno is coming from. That's why you need
> > debug statements - you know it's going into
> > smb_iconv() but you don't know where it's
> > going from there.
> > 
> > Jeremy.
> > 
> 
> At least those proved that neither Solaris' nor GNU's iconv were
> involved :-)
> 
> I tagged all the possibles causes for EILSEQ, so here's the code causing
> that issue, in lib/util/charset/iconv.c:
> 
> if ((c[0] & 0xf0) == 0xe0) {
> if (in_left < 3 ||
> (c[1] & 0xc0) != 0x80 ||
> (c[2] & 0xc0) != 0x80) {
> errno = EILSEQ;
> DEBUG(3,("DEBUG, %d, %d, %d, %d\n",
> in_left, c[0], c[1], c[2]));
> goto error;
> }
> 
> It happens because in_left == 2 when it should be 3:
> 
> [2013/09/06 20:59:50.249004,  3] ../lib/util/charset/iconv.c:600(utf8_pull)
>   DEBUG, 2, 226, 153, 187
> [2013/09/06 20:59:50.249056,  3] lib/charcnv.c:161(convert_string_internal)
>   convert_string_internal: Conversion error: Illegal multibyte
> sequence(â<99>»_Corbeille)
> 
> The sequence values are good, as this char is 0xE2 0x99 0xBB in UTF8.
> 
> I tried to backtrack the origin of this value, but I got lost after
> convert_string_internal() in source3/lib/charcnv.c , where it was
> incorrect already.
> 
> Is it getting warmer?

Yes ! The tests against 0x80 are correct, so as you've
surmised it's the in_left == 2 is the real problem.

If after the DEBUG(3,("..)) statement you have
here you cause it to terminate with abort(),
then you can catch the backtrace if you set

panic action = /bin/sleep 99

in the [global] section of your smb.conf. At
that point you should be able to attach to
the parent process of the sleep (which will
be an smbd) with gdb, and examine the contents
of i_len inside convert_string_internal().

Either that or add another debug inside
convert_string_internal() to print out
the values of srclen and i_len at various
points and try and determine why it's off
by one.

Cheers,

Jeremy.
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Re: [Samba] AD DC eventually not browsable without restart

[Ricky Nance]

What about log.smbd ... also what does samba-tool processes output?

Ricky


On Fri, Sep 6, 2013 at 12:57 PM, Kevin Field  wrote:

> (Just for the record, I haven't restarted samba in a couple weeks now.)
>
> That's very interesting: via the IP, it is browsable.
>
> As for the outputs:
>
> $ sudo netstat -anp | grep "samba\|smb"
> tcp0  0 0.0.0.0:139 0.0.0.0:* LISTEN
>  5714/samba
> tcp0  0 0.0.0.0:464 0.0.0.0:* LISTEN
>  19028/samba
> tcp0  0 0.0.0.0:53  0.0.0.0:* LISTEN
>  19035/samba
> tcp0  0 0.0.0.0:88  0.0.0.0:* LISTEN
>  19028/samba
> tcp0  0 0.0.0.0:636 0.0.0.0:* LISTEN
>  19026/samba
> tcp0  0 0.0.0.0:445 0.0.0.0:* LISTEN
>  19034/samba
> tcp0  0 0.0.0.0:10240.0.0.0:* LISTEN
>  19023/samba
> tcp0  0 0.0.0.0:32680.0.0.0:* LISTEN
>  19026/samba
> tcp0  0 0.0.0.0:32690.0.0.0:* LISTEN
>  19026/samba
> tcp0  0 0.0.0.0:389 0.0.0.0:* LISTEN
>  19026/samba
> tcp0  0 0.0.0.0:135 0.0.0.0:* LISTEN
>  19023/samba
> tcp0  0 10.0.1.2:44510.0.1.1:1777
> ESTABLISHED 19044/samba
> tcp0  0 10.0.1.2:1024   10.0.1.1:3024
> ESTABLISHED 19023/samba
> tcp0  0 10.0.1.2:44510.0.1.1:2130
> ESTABLISHED 5714/samba
> tcp0  0 10.0.1.2:58561  10.0.1.1:1025
> ESTABLISHED 19029/samba
> udp0  0 10.0.1.2:3890.0.0.0:*
> 19027/samba
> udp0  0 0.0.0.0:389 0.0.0.0:*
> 19027/samba
> udp0  0 10.0.1.2:1370.0.0.0:*
> 19024/samba
> udp0  0 10.255.255.255:137  0.0.0.0:*
> 19024/samba
> udp0  0 0.0.0.0:137 0.0.0.0:*
> 19024/samba
> udp0  0 10.0.1.2:1380.0.0.0:*
> 19024/samba
> udp0  0 10.255.255.255:138  0.0.0.0:*
> 19024/samba
> udp0  0 0.0.0.0:138 0.0.0.0:*
> 19024/samba
> udp0  0 0.0.0.0:53  0.0.0.0:*
> 19035/samba
> udp0  0 10.0.1.2:4640.0.0.0:*
> 19028/samba
> udp0  0 0.0.0.0:464 0.0.0.0:*
> 19028/samba
> udp0  0 10.0.1.2:88 0.0.0.0:*
> 19028/samba
> udp0  0 0.0.0.0:88  0.0.0.0:*
> 19028/samba
> unix  2  [ ] DGRAM1900834 5714/samba
>   /var/lib/samba/private/smbd.**tmp/msg/msg.5714
> unix  2  [ ACC ] STREAM LISTENING 413329 19023/samba
>  /var/run/samba/ncalrpc/np/**dnsserver
> unix  2  [ ACC ] STREAM LISTENING 413331 19023/samba
>  /var/run/samba/ncalrpc/np/**ntsvcs
> unix  2  [ ACC ] STREAM LISTENING 413334 19023/samba
>  /var/run/samba/ncalrpc/np/**browser
> unix  2  [ ACC ] STREAM LISTENING 413336 19023/samba
>  /var/run/samba/ncalrpc/np/**unixinfo
> unix  2  [ ACC ] STREAM LISTENING 413339 19023/samba
>  /var/run/samba/ncalrpc/np/**protected_storage
> unix  2  [ ACC ] STREAM LISTENING 413344 19023/samba
>  /var/run/samba/ncalrpc/np/**spoolss
> unix  2  [ ] DGRAM413345 19025/samba
>  /var/lib/samba/private/smbd.**tmp/msg/msg.19025
> unix  2  [ ACC ] STREAM LISTENING 413347 19023/samba
>  /var/run/samba/ncalrpc/np/**lsass
> unix  2  [ ACC ] STREAM LISTENING 413350 19023/samba
>  /var/run/samba/ncalrpc/np/**lsarpc
> unix  2  [ ACC ] STREAM LISTENING 413352 19023/samba
>  /var/run/samba/ncalrpc/np/**netlogon
> unix  2  [ ACC ] STREAM LISTENING 413354 19023/samba
>  /var/run/samba/ncalrpc/np/samr
> unix  2  [ ACC ] STREAM LISTENING 413356 19023/samba
>  /var/run/samba/ncalrpc/np/**rpcecho
> unix  2  [ ACC ] STREAM LISTENING 413358 19023/samba
>  /var/run/samba/ncalrpc/DEFAULT
> unix  2  [ ACC ] STREAM LISTENING 413363 19023/samba
>  /var/run/samba/ncalrpc/np/**wkssvc
> unix  2  [ ACC ] STREAM LISTENING 413404 19031/samba
>  /var/lib/samba/ntp_signd/**socket
> unix  2  [ ACC ] STREAM LISTENING 413365 19023/samba
>  /var/run/samba/ncalrpc/**EPMAPPER
> unix  2  [ ] DGRAM413367 19026/samba
>  /var/lib/samba/private/smbd.**tmp/msg/msg.19026
> unix  2  [ ACC ] STREAM LISTENING 413372 19023/samba
>  /var/run/samba/ncalrpc/np/**epmapper
> unix  2  [ ] DGRAM413374 19027/samba
>  /var/lib/samba/private/smbd.**tmp/msg/msg.19027
> unix  2  [ ] DGRAM413382 19028/samba
>  /var/lib/samba/private/smbd.**tmp/msg/msg.19028
> unix  2  [ ] DGRAM

Re: [Samba] AD DC eventually not browsable without restart

[Ricky Nance]

Next time its unresponsive, try hitting it with \\ip.to.new.dc and see if
its browsable, also get the output of netstat -anp | grep "samba\|smbd"  as
well as tail -n 50 /usr/local/samba/var/log.samba and tail -n 50
usr/local/samba/var/log.smbd (adjust the path as needed), also I am
interested if top has anything to say about samba or smbd (as for processor
and memory usage).

Ricky


On Fri, Sep 6, 2013 at 12:12 PM, Kevin Field  wrote:

> Yep, that's exactly it.  Thanks!
>
> Kev
>
>
> On 2013-09-06 10:16 AM, Ricky Nance wrote:
>
>> Have you disabled syslinux? That is what that change looks like to me.
>>
>> Ricky
>>
>>
>> On Thu, Sep 5, 2013 at 3:26 PM, Kevin Field > > wrote:
>>
>> I just noticed something interesting, since I have /etc under
>> version control: /etc/mtab changed thusly:
>>
>> -tmpfs /dev/shm tmpfs
>> rw,rootcontext="system_u:__**object_r:tmpfs_t:s0" 0 0
>>
>> +tmpfs /dev/shm tmpfs rw 0 0
>>
>> Does this mean anything to our troubleshooting?
>>
>> Thanks,
>> Kev
>>
>>
>> On 2013-09-04 2:02 PM, Kevin Field wrote:
>>
>> Yeah, it's still
>>
>> tmpfs 5.9G 0  5.9G   0% /dev/shm
>>
>> The really odd thing is, currently, it's telling me this if I try
>> to
>> access it from OLDDC, running Windows Server 2003.  But if I
>> remote into
>> another computer (GEYSER) on the network that's running Windows
>> XP, I
>> can access \\NEWDC just fine.  Back to OLDDC and it still
>> doesn't work.
>>
>> Besides the OS I noticed another difference, running "echo
>> %logonserver%" from GEYSER, it reports \\G5, whereas running that
>> on
>> OLDDC reports \\OLDDC.  I know this is normal behaviour, but I
>> wonder if
>> it has anything to do with it.  I also wonder if, if I leave
>> GEYSER
>> logged in long enough, I'll have the same result on it as I do
>> on OLDDC.
>>
>> So nobody else is having this browsability problem, eh?
>>
>> Kev
>>
>> On 2013-08-24 1:41 PM, Kevin Field wrote:
>>
>> Hmm...it hasn't been long enough since a restart yet,
>> because it's not
>> doing it ATM, but nonetheless if it's a question of an extra
>> 45 mb I
>> think we have it covered:
>>
>> tmpfs 5.9G 0  5.9G   0% /dev/shm
>>
>> But I'll check anyway next opportunity and report back if
>> it's a
>> positive.
>>
>> Kev
>>
>> On 2013-08-24 11:51 AM, Ricky Nance wrote:
>>
>> I wonder if your hitting the /run/lock fill up that
>> another user
>> reported on a week or two ago (they are using ubuntu). I
>> think the
>> solution was to make that tmpfs partition bigger (like
>> 50 mb instead of
>> 5 mb). next time it is unresponsive check and see what
>> the output of 'df
>> -h' is.
>>
>> Ricky
>>
>>
>> On Sat, Aug 24, 2013 at 10:02 AM, Kevin Field
>> mailto:k...@brantaero.com>
>> >>
>>
>> wrote:
>>
>>  I've upgraded to 4.0.9 and this behaviour persists.
>>
>>  Should I file a bug report, do you think? �Is
>> nobody else
>>  experiencing this?
>>
>>  Thanks,
>>
>>  Kev
>>
>>  On 2013-08-20 11:40 AM, Kristofer Pettijohn wrote:
>>
>>  You may want to see if it is this bug, which is
>> fixed in 4.0.9:
>> 
>> https://bugzilla.samba.org/___**_show_bug.cgi?id=9820
>> 
>> 
>> >
>>
>> 
>> 
>> 
>> 
>> >>
>>
>>
>>
>>
>> --**
>> --**--__--__
>>
>>
>>
>>
>>  *From: *"Kevin Field" > 
>> >>
>>  *To: *samba@lists.samba.org
>> 
>> >
>> **>
>>  *Sent: *Tuesday, August 20, 2013 9:38:32 AM
>>  *Subject: *[Samb

Re: [Samba] Conversion error: Illegal multibyte sequence

[Jeremy Allison]

On Sat, Sep 07, 2013 at 02:02:26AM +0200, Laurent Blume wrote:
> On 2013-09-06 10:54 PM, Jeremy Allison wrote:
> 
> > Either that or add another debug inside
> > convert_string_internal() to print out
> > the values of srclen and i_len at various
> > points and try and determine why it's off
> > by one.
> 
> Well, it was /quite/ further than that.
> 
> I think I got it this time, in sources3/smbd/mangle_hash2.c:
> 
>/*
>  * Note that if CH_UNIX is utf8 a string may be 3
>  * bytes, but this is ok as mb utf8 characters don't
>  * contain embedded ascii bytes. We are really
> checking
>  * for mb UNIX asian characters like Japanese
> (SJIS) here.
>  * JRA.
>  */
> DEBUG(3, ("DEBUG ++ name, %s\n", name));
> if (convert_string(CH_UNIX, CH_UTF16LE,
> name, 2, mbc, 2, False) == 2) {
> /* Was a good mb string. */
> name += 2;
> continue;
> }
> DEBUG(3, ("DEBUG -- name, %s\n", name));
> 
> 
> Why is the length here hardcoded to 2?
> 
> It's past 2am around here, so I could be missing something, time for bed.

Woo hoo ! I think you've found an oold old bug :-).

I'll take a look at that asap.

Thanks !

Jeremy.
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Re: [Samba] Conversion error: Illegal multibyte sequence

[Laurent Blume]

On 2013-09-06 10:54 PM, Jeremy Allison wrote:

> Either that or add another debug inside
> convert_string_internal() to print out
> the values of srclen and i_len at various
> points and try and determine why it's off
> by one.

Well, it was /quite/ further than that.

I think I got it this time, in sources3/smbd/mangle_hash2.c:

   /*
 * Note that if CH_UNIX is utf8 a string may be 3
 * bytes, but this is ok as mb utf8 characters don't
 * contain embedded ascii bytes. We are really
checking
 * for mb UNIX asian characters like Japanese
(SJIS) here.
 * JRA.
 */
DEBUG(3, ("DEBUG ++ name, %s\n", name));
if (convert_string(CH_UNIX, CH_UTF16LE,
name, 2, mbc, 2, False) == 2) {
/* Was a good mb string. */
name += 2;
continue;
}
DEBUG(3, ("DEBUG -- name, %s\n", name));


Why is the length here hardcoded to 2?

It's past 2am around here, so I could be missing something, time for bed.

Thanks,

Laurent

-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

[Samba] Samba 4 "TKEY is unacceptable" driving me NUTS!

[Patrick Gray]

I've installed Samba 4.09 on ubuntu with bind 9.8.1-P1, the former compiled 
from git source and the latter installed from apt-get. I'm migrating from an 
existing Windows 2008 SBS domain controller that I want to retire (and be 
Windows free on the server side), and have followed the instructions on the 
Samba wiki for setting up Bind and migrating.

When I run a samba_dnsupate -verbose -all-names as per the wiki, all updates 
result in a "dns_tkey_negotiategss: TKEY is unacceptable". Syslog produces the 
following:

Sep  6 12:21:32 newdc samba[7735]: [2013/09/06 12:21:32.189272,  0] 
../source4/dsdb/dns/dns_update.c:294(dnsupdate_nameupdate_done)
Sep  6 12:21:32 newdc samba[7735]:   ../source4/dsdb/dns/dns_update.c:294: 
Failed DNS update - NT_STATUS_IO_TIMEOUT
Sep  6 12:23:29 newdc named[7690]: samba b9_putrr: unhandled record type 0

The same TKEY error occurred when I attempt a manual nsupdate. What's odd is 
that the updates actually appear in the Windows DNS manager when I use nsupdate 
or samba-tool to add entries. This works for both the new samba DC and the 
existing windows DC. I was going to chalk this up to gremlins and move on with 
life, but when I attempt to transfer or seize the naming role, from either 
samba or the existing Windows DC, I get:

sudo /usr/local/samba/bin/samba-tool fsmo transfer --role=naming -Uadministrator
ERROR(ldb): uncaught exception - Failed FSMO transfer: WERR_GENERAL_FAILURE
  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/fsmo.py", 
line 268, in run
transfer_role(self.outf, role, samdb)
  File "/usr/local/samba/lib/python2.7/site-packages/samba/netcmd/fsmo.py", 
line 53, in transfer_role
samdb.modify(m)

I believe these are related, but I cannot get the TKEY error resolved and have 
attempted every trick I've been able to find on this mailing list. I've tried 
the following based on days of googling:


  1.  Verified that apparmor isn't causing problems by setting the following in 
it's config:

  # Samba 4 support
  /usr/local/samba/private/** rkw,
  /usr/local/samba/private/dns.keytab rk,
  /usr/local/samba/private/dns/** rkw,
  /etc/krb5.conf r,
  /usr/local/samba/etc/smb.conf r,

  #Samba 4 BIND libraries
  /usr/local/samba/lib/bind9/dlz_bind9.so rm,
  /usr/local/samba/lib/** rm,
  /usr/lib/x86_64-linux-gnu/ldb/modules/ldb/** rm,

  # with libdlz_bind9, named needs to access /var/tmp/DNS-${HOSTNAME}_xxx ticke$
  /var/tmp/** krw,
  /tmp/** krw,

2. Regenerated the dns.keytab
3. Ensured that the new DC is listed as the SOA record in the DNS for 
mydomain.local
4. Added the requested config to my named.com:

tkey-gssapi-keytab "/usr/local/samba/private/dns.keytab";
#tried with and without the line below, no difference
tkey-domain "MYDOMAIN.LOCAL";
5. Attempted to transfer and seize roles from both Windows and Samba

I've run out of ideas here, and would appreciate any help or additional things 
to attempt. If I cannot seize the naming role, shutting down the windows box 
results in syslog being flooded with "Can't contact OLDDC.mydomain.local"-type 
errors. I want to rid the domain of all memories of SBS so I'm worried that not 
migrating the naming role will keep some dependency in place.

Thanks for any help!

Kind Regards,

Pat
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Re: [Samba] AD DC eventually not browsable without restart

[Kevin Field]

Yep, that's exactly it.  Thanks!

Kev

On 2013-09-06 10:16 AM, Ricky Nance wrote:

Have you disabled syslinux? That is what that change looks like to me.

Ricky


On Thu, Sep 5, 2013 at 3:26 PM, Kevin Field mailto:k...@brantaero.com>> wrote:

I just noticed something interesting, since I have /etc under
version control: /etc/mtab changed thusly:

-tmpfs /dev/shm tmpfs
rw,rootcontext="system_u:__object_r:tmpfs_t:s0" 0 0
+tmpfs /dev/shm tmpfs rw 0 0

Does this mean anything to our troubleshooting?

Thanks,
Kev


On 2013-09-04 2:02 PM, Kevin Field wrote:

Yeah, it's still

tmpfs 5.9G 0  5.9G   0% /dev/shm

The really odd thing is, currently, it's telling me this if I try to
access it from OLDDC, running Windows Server 2003.  But if I
remote into
another computer (GEYSER) on the network that's running Windows
XP, I
can access \\NEWDC just fine.  Back to OLDDC and it still
doesn't work.

Besides the OS I noticed another difference, running "echo
%logonserver%" from GEYSER, it reports \\G5, whereas running that on
OLDDC reports \\OLDDC.  I know this is normal behaviour, but I
wonder if
it has anything to do with it.  I also wonder if, if I leave GEYSER
logged in long enough, I'll have the same result on it as I do
on OLDDC.

So nobody else is having this browsability problem, eh?

Kev

On 2013-08-24 1:41 PM, Kevin Field wrote:

Hmm...it hasn't been long enough since a restart yet,
because it's not
doing it ATM, but nonetheless if it's a question of an extra
45 mb I
think we have it covered:

tmpfs 5.9G 0  5.9G   0% /dev/shm

But I'll check anyway next opportunity and report back if it's a
positive.

Kev

On 2013-08-24 11:51 AM, Ricky Nance wrote:

I wonder if your hitting the /run/lock fill up that
another user
reported on a week or two ago (they are using ubuntu). I
think the
solution was to make that tmpfs partition bigger (like
50 mb instead of
5 mb). next time it is unresponsive check and see what
the output of 'df
-h' is.

Ricky


On Sat, Aug 24, 2013 at 10:02 AM, Kevin Field
mailto:k...@brantaero.com>
>>
wrote:

 I've upgraded to 4.0.9 and this behaviour persists.

 Should I file a bug report, do you think? �Is
nobody else
 experiencing this?

 Thanks,

 Kev

 On 2013-08-20 11:40 AM, Kristofer Pettijohn wrote:

 You may want to see if it is this bug, which is
fixed in 4.0.9:
https://bugzilla.samba.org/show_bug.cgi?id=9820


>





--__--__



 *From: *"Kevin Field" mailto:k...@brantaero.com>
>>
 *To: *samba@lists.samba.org

>
 *Sent: *Tuesday, August 20, 2013 9:38:32 AM
 *Subject: *[Samba] AD DC eventually not
browsable without
restart


 I have a SerNet Samba 4.0.8 AD DC running on
CentOS 6.4 (newdc)
 replicating from a W2K3 DC (olddc). �When I
first launch Samba
using
 `sudo samba`, I can go to the Windows server
and browse to
 \\newdc in
 Explorer, and I see mytestshare, netlogon,
printers, sysvol, and
 "Printers and Faxes".

 After a while (I'm not sure how long precisely,
but under 24
 hours) I
 could not navigate to \\newdc without the
following error:

 ---
 \\newdc
 ---
 \\newdc is not accessible. You might not have
 

Re: [Samba] AD DC eventually not browsable without restart

[Ricky Nance]

Have you disabled syslinux? That is what that change looks like to me.

Ricky


On Thu, Sep 5, 2013 at 3:26 PM, Kevin Field  wrote:

> I just noticed something interesting, since I have /etc under version
> control: /etc/mtab changed thusly:
>
> -tmpfs /dev/shm tmpfs rw,rootcontext="system_u:**object_r:tmpfs_t:s0" 0 0
> +tmpfs /dev/shm tmpfs rw 0 0
>
> Does this mean anything to our troubleshooting?
>
> Thanks,
> Kev
>
>
> On 2013-09-04 2:02 PM, Kevin Field wrote:
>
>> Yeah, it's still
>>
>> tmpfs 5.9G 0  5.9G   0% /dev/shm
>>
>> The really odd thing is, currently, it's telling me this if I try to
>> access it from OLDDC, running Windows Server 2003.  But if I remote into
>> another computer (GEYSER) on the network that's running Windows XP, I
>> can access \\NEWDC just fine.  Back to OLDDC and it still doesn't work.
>>
>> Besides the OS I noticed another difference, running "echo
>> %logonserver%" from GEYSER, it reports \\G5, whereas running that on
>> OLDDC reports \\OLDDC.  I know this is normal behaviour, but I wonder if
>> it has anything to do with it.  I also wonder if, if I leave GEYSER
>> logged in long enough, I'll have the same result on it as I do on OLDDC.
>>
>> So nobody else is having this browsability problem, eh?
>>
>> Kev
>>
>> On 2013-08-24 1:41 PM, Kevin Field wrote:
>>
>>> Hmm...it hasn't been long enough since a restart yet, because it's not
>>> doing it ATM, but nonetheless if it's a question of an extra 45 mb I
>>> think we have it covered:
>>>
>>> tmpfs 5.9G 0  5.9G   0% /dev/shm
>>>
>>> But I'll check anyway next opportunity and report back if it's a
>>> positive.
>>>
>>> Kev
>>>
>>> On 2013-08-24 11:51 AM, Ricky Nance wrote:
>>>
 I wonder if your hitting the /run/lock fill up that another user
 reported on a week or two ago (they are using ubuntu). I think the
 solution was to make that tmpfs partition bigger (like 50 mb instead of
 5 mb). next time it is unresponsive check and see what the output of 'df
 -h' is.

 Ricky


 On Sat, Aug 24, 2013 at 10:02 AM, Kevin Field >>> > wrote:

 I've upgraded to 4.0.9 and this behaviour persists.

 Should I file a bug report, do you think? �Is nobody else
 experiencing this?

 Thanks,

 Kev

 On 2013-08-20 11:40 AM, Kristofer Pettijohn wrote:

 You may want to see if it is this bug, which is fixed in 4.0.9:
 
 https://bugzilla.samba.org/__**show_bug.cgi?id=9820
 
 
 >




 --**__**
 --__



 *From: *"Kevin Field" >>> >
 *To: *samba@lists.samba.org 
 *Sent: *Tuesday, August 20, 2013 9:38:32 AM
 *Subject: *[Samba] AD DC eventually not browsable without
 restart


 I have a SerNet Samba 4.0.8 AD DC running on CentOS 6.4 (newdc)
 replicating from a W2K3 DC (olddc). �When I first launch Samba
 using
 `sudo samba`, I can go to the Windows server and browse to
 \\newdc in
 Explorer, and I see mytestshare, netlogon, printers, sysvol, and
 "Printers and Faxes".

 After a while (I'm not sure how long precisely, but under 24
 hours) I
 could not navigate to \\newdc without the following error:

 ---
 \\newdc
 ---
 \\newdc is not accessible. You might not have permission to
 use this
 network resource. Contact the administrator of this server to
 find out
 if you have access permissions.

 The Server service is not started.
 ---
 OK
 ---

 But in the interim, I had not been doing anything in the system,
 so I'm
 not sure what might have caused it. �One time it even happened
 on a
 weekend when no backup or anything particularly special is
 scheduled
 while I was away.

 Anyway, running `sudo killall samba` and then `sudo samba`
 makes it
 suddenly browsable again.

 This is happening every day. �I guess it would be best to figure
 this
 problem out before we make Samba the only DC.

 Here's my smb.conf, mostly set up by samba-tool, and now a
 work in
 progress to add the extras we will use:

 # Global parameters
 [gl

Re: [Samba] samba Digest, Vol 129, Issue 6

[paulw]

I am Currently out of the office and will return on Monday 9th September.
My email will not be monitor , so if you require assistance please email 
supp...@swift-computing.co.uk.

-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Re: [Samba] primary GID based access for user in 16 supplementary groups

[Burgess, Adam]

Regarding NFS/GSS/KRB5 I know of the ktkt_warnd but that in itself is nowhere 
near enough - that just renews renewable tickets.  Session based cred caches 
issue I would think is not solved (how does gssd know which ticket to use for a 
user context on NFS client) - I know it always worked for uid based ones.  All 
this of course is moot as I am sure it will be a 100PD project minimum.

ACLs we use are accessed from UNIX (Solaris/HPUX/potentially Linux) clients 
(over NFS) and from Windows (XP/2K3/2K8/7) clients (over SMB/CIFS).  Hence 
proper unification is required.  16 group limit stays with us and any group 
samba sees for membership is what will be seen by UNIX NSS (aside from PGID of 
course).

Regarding technical user group, I will request to join now.  

BTW, regarding PACs since you are there asking about their decoding) do you 
happen to know if future versions of Samba will use the user account SID to 
lookup the user name for UNIX account (ie get AD SID, then get UNIX UID, then 
get UNIX account name) when determining the actual UNIX account context, rather 
than the way it works now which relies on cr4ppy string case adjustments which 
is not technically clean and requires the UNIX account name to match the 
Windows sAMAccountName to some extent?  As it stands you could not have two 
accounts with the same samAccountName in two different AD domains accessing the 
same service, without using the mess of username mappings.  Not important for 
us right now but just thought I would throw it out there.

-Original Message-
From: Tris Mabbs [mailto:tm-samba201...@firstgrade.co.uk] 
Sent: 06 September 2013 13:01
To: Burgess, Adam
Cc: samba@lists.samba.org
Subject: RE: [Samba] primary GID based access for user in 16 supplementary 
groups

Hiya Adam,

> Thanks again.

You're welcome - sorry I don't seem to be being much help :-(

> We would love to move to RPCSEC_GSS KRB5 based authorization for NFS - 
> but
that in itself is a major project.  I looked at this thoroughly 8 years ago 
(and had it functionally working, long before Linux even had NFSv4)

It's (fortunately, 'cause it really needed it ...) substantially been 
improved:

> but it was not really operationally viable for certain reasons (such 
> as i)
unattended operations needing automatic ticket renewal past the final expiry 
time which requires keytab stores for such accounts with password rollover 
processes etc, ii) session based credentials caches as used with ticket 
forwarding,

Since "Solaris 10" (I believe that's what you're using from your other 
post?) 6/06, that's (theoretically ...) all handled for you by "ktkt_warnd".
I.e., somewhat since your last looking at it - might be worth a quick 
look at again, depending on how up-to-date your "Solaris 10" boxes are, of 
course ...  And "ktkt_warnd" may not know what's needed, depending on how your 
Samba Kerberos interacts with the system Kerberos - it's more designed for 
maintenance of tickets issued as the result of interactive logins - but it 
might be worth a quick play around with just to see ...

> iii) and the NFS id mapping and gsscred system was far from 
> operationally
viable).  This may have improved a little since I looked at it before but I 
suspect not too much so would need hundreds of many days work for myself to 
code operational solutions.

Hopefully not - "ktkt_warnd" should already (hopefully) be able to do 
most of what you'd need to code, and the NFS id mapping/GSS/... system does 
seem to work properly, or at least acceptably, now.  We use it ourselves for 
NFS mounting some filesystems from "Server 2008 R2" boxes, and all the ID 
mapping actually works correctly (much to my surprise - Soracle playing nicely 
with Microsoft?! ...).

> Actually Kerberos/GSSAPI/SSPI is an area I am (dare I say it) quite 
> expert
and I have Samba configured in a way which is as much as possible using only 
Kerberos (via dedicated keytab etc, only the annoying secrets.tdb computer 
password store prevents it from being a "proper" Kerberos implementation).
I have used Centrify too, btw.
> As for ACLs - I am afraid they are required! Again because of the 16 
> group
limitation!  If all file objects use owner GID access control only then you 
end up with many separate "groups" of accounts needing to be in that resource 
group which implies also a user ends up being in many many groups.

Yes, that could be a problem, unless you can use something other than 
AUTH_SYS ...
However, if the ACL is being applied at the point of access (Samba), 
based on the AD groups, then it is less of a problem anyway.  You're not 
worrying about group access being passed over-the-wire for NFS, because it's 
Samba that's applying the constructed ACL based on the AD group membership
(*and* any underlying filesystem permissions, but if Samba is the only point of 
access then that's not a problem anyway).
I.e., if Samba is th

Re: [Samba] Samba4 LDAP Integration with Asterisk

[Rowland Penny]

On 06/09/13 11:04, Victor Adsuar Abaldea wrote:

Hi,

I am turning crazy. I try to integrate Asterisk 11.5.1 into Samba4 LDAP,
but when I import the ldif file from contrib directory I get this error.

ldbmodify -H /usr/local/samba/private/sam.ldb asterisk.ldif
--option="dsdb:schema update allowed"=true
ERR: (No such object) "objectclass: Cannot add
cn=asterisk,cn=schema,cn=config, parent does not exist!" on DN
cn=asterisk,cn=schema,cn=config at block before line 835
Modify failed after processing 0 records

LDAP and Asterisk are in diferents boxes. Please can someone help me?

Thank you in advance!

  *Victor Adsuar*
*Departamento de Sistemas*
*Teralco Tecnologías Informáticas*
vads...@teralco.com
www.teralco.com

*AVISO LEGAL:
Este mensaje se dirige exclusivamente a su destinatario y puede contener
información reservada y/o CONFIDENCIAL. Si Vd. no es el destinatario
original no está autorizado a copiar o distribuir esta comunicación a
ninguna otra persona. Si ha recibido este mensaje por error, le rogamos nos
lo comunique inmediatamente por esta misma vía y proceda a su borrado. **
Gracias**.*


*DISCLAIMER:
This message is intended exclusively for its addressee and may contain
information that is CONFIDENTIAL and protected by professional privilege.
If you are not the intended recipient you are hereby notified that any
dissemination, copy or disclosure of this communication is strictly
prohibited by law. If this message has been received in error, please
immediately notify us via e-mail and delete it. **Thank** you.*

*
*

*
*

*Antes de imprimir este email piense bien si es necesario hacerlo.*

*Cosider your environmental responsibility before printing this enail*
Hi, split the ldif in two, one containing the attributes, the other the 
objectclasses, add the attributes one first, then the objectclasses.


Rowland

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Re: [Samba] primary GID based access for user in 16 supplementary groups

[Tris Mabbs]

Hiya Adam,

> Thanks again.

You're welcome - sorry I don't seem to be being much help :-(

> We would love to move to RPCSEC_GSS KRB5 based authorization for NFS - but
that in itself is a major project.  I looked at this thoroughly 8 years ago
(and had it functionally working, long before Linux even had NFSv4)

It's (fortunately, 'cause it really needed it ...) substantially
been improved:

> but it was not really operationally viable for certain reasons (such as i)
unattended operations needing automatic ticket renewal past the final expiry
time which requires keytab stores for such accounts with password rollover
processes etc, ii) session based credentials caches as used with ticket
forwarding,

Since "Solaris 10" (I believe that's what you're using from your
other post?) 6/06, that's (theoretically ...) all handled for you by
"ktkt_warnd".
I.e., somewhat since your last looking at it - might be worth a
quick look at again, depending on how up-to-date your "Solaris 10" boxes
are, of course ...  And "ktkt_warnd" may not know what's needed, depending
on how your Samba Kerberos interacts with the system Kerberos - it's more
designed for maintenance of tickets issued as the result of interactive
logins - but it might be worth a quick play around with just to see ...

> iii) and the NFS id mapping and gsscred system was far from operationally
viable).  This may have improved a little since I looked at it before but I
suspect not too much so would need hundreds of many days work for myself to
code operational solutions.

Hopefully not - "ktkt_warnd" should already (hopefully) be able to
do most of what you'd need to code, and the NFS id mapping/GSS/... system
does seem to work properly, or at least acceptably, now.  We use it
ourselves for NFS mounting some filesystems from "Server 2008 R2" boxes, and
all the ID mapping actually works correctly (much to my surprise - Soracle
playing nicely with Microsoft?! ...).

> Actually Kerberos/GSSAPI/SSPI is an area I am (dare I say it) quite expert
and I have Samba configured in a way which is as much as possible using only
Kerberos (via dedicated keytab etc, only the annoying secrets.tdb computer
password store prevents it from being a "proper" Kerberos implementation).
I have used Centrify too, btw.
> As for ACLs - I am afraid they are required! Again because of the 16 group
limitation!  If all file objects use owner GID access control only then
you end up with many separate "groups" of accounts needing to be in that
resource group which implies also a user ends up being in many many groups.

Yes, that could be a problem, unless you can use something other
than AUTH_SYS ...
However, if the ACL is being applied at the point of access (Samba),
based on the AD groups, then it is less of a problem anyway.  You're not
worrying about group access being passed over-the-wire for NFS, because it's
Samba that's applying the constructed ACL based on the AD group membership
(*and* any underlying filesystem permissions, but if Samba is the only point
of access then that's not a problem anyway).
I.e., if Samba is the only way by which the ACLs need to be applied
to the NFS mounted filesystem, it shouldn't matter whether NFS is handling
the groups correctly because it's never having to.  The only group
authentication presented over NFS will be the primary group; because it's
the primary group, that will always be in the NFS group list anyway (it's
the supplementary groups that overflow the 16 group limit).
Now if you're needing to regulate access for other points of access
as well (E.g., local processes) then that doesn't necessarily work; if it's
just via Samba then it should work regardless (though remember to recompile
Samba if you change the kernel group limit or it will all core-dump on you
...).

> Actually in the most part I find they work very well, and Samba almost
behaves correctly these days when evaluating them - the only issue I have
seen is with directory defaults as Samba decides to manage file creation ACL
inheritance itself rather than allowing OS posix ACL defaults to be applied
(eg. issue with insecure execute bit being applied to newly created files
because this is required for newly created directories to allow change dir
access etc).

Particularly with Samba, it all gets horrendously more complex
because of mapping DOS attributes onto permissions bits (as you're obviously
aware), which can leave you with some extremely strange permissions being
set at the filesystem level and all sorts of headaches.  E.g., as you
mention, execute bits being applied to newly created files ...
If you're not mapping DOS attributes through Samba then it's all
much simpler and more predictable.
Still don't like the little perishers though! :-)

> Essentially you have to imagine the groups we see evaluated via Samba user
context will be identical as those for a UNIX login for

Re: [Samba] primary GID based access for user in 16 supplementary groups

[Burgess, Adam]

Thanks again.

We would love to move to RPCSEC_GSS KRB5 based authorization for NFS - but that 
in itself is a major project.  I looked at this thoroughly 8 years ago (and had 
it functionally working, long before Linux even had NFSv4) but it was not 
really operationally viable for certain reasons (such as i) unattended 
operations needing automatic ticket renewal past the final expiry time which 
requires keytab stores for such accounts with password rollover processes etc, 
ii) session based credentials caches as used with ticket forwarding, iii) and 
the NFS id mapping and gsscred system was far from operationally viable).  This 
may have improved a little since I looked at it before but I suspect not too 
much so would need hundreds of many days work for myself to code operational 
solutions.  Actually Kerberos/GSSAPI/SSPI is an area I am (dare I say it) quite 
expert and I have Samba configured in a way which is as much as possible using 
only Kerberos (via dedicated keytab etc, only the annoying
  secrets.tdb computer password store prevents it from being a "proper" 
Kerberos implementation).  I have used Centrify too, btw.

As for ACLs - I am afraid they are required! Again because of the 16 group 
limitation!  If all file objects use owner GID access control only then you 
end up with many separate "groups" of accounts needing to be in that resource 
group which implies also a user ends up being in many many groups.  Actually in 
the most part I find they work very well, and Samba almost behaves correctly 
these days when evaluating them - the only issue I have seen is with directory 
defaults as Samba decides to manage file creation ACL inheritance itself rather 
than allowing OS posix ACL defaults to be applied (eg. issue with insecure 
execute bit being applied to newly created files because this is required for 
newly created directories to allow change dir access etc).

Essentially you have to imagine the groups we see evaluated via Samba user 
context will be identical as those for a UNIX login for the same user - it is 
completely unified.  That is all except for the UNIX PGID!!!

Regarding posting my questions in the technical group I thought this was not 
allowed for non-samba developers, otherwise both of my current queries would 
already have been sent there.

Adam

-Original Message-
From: Tris Mabbs [mailto:tm-samba201...@firstgrade.co.uk] 
Sent: 06 September 2013 10:15
To: Burgess, Adam
Cc: samba@lists.samba.org
Subject: RE: [Samba] primary GID based access for user in 16 supplementary 
groups

Hiya Adam,

> We have not seen any issue with primary group not matching 
> file/directory
group owner - but I will look out for this in future.  

Yes, it was a bit of an obscure one to track down, and I'm still not convinced 
I've got to the bottom of it - we have a working solution now and that's where 
I had to stop poking around.  Thought I'd mention it though in case it applied 
in your case.

> We are using NFSv4 but as I understood it this still uses AUTH_SYS
authentication method by default and this is what prevents us moving to >16 
groups. ...

Well yes, and no.
Using AUTH_SYS will trip the 16 group limit problem, yes.  That's part of the 
definition for NFS defined in RFC - that's where 
the 16 group limit comes from and it's not tuneable.
Were you to be using Linux, there's a "magic" hack which gets around this, by 
ignoring the group list supplied by NFS and looking up the membership for 
itself.  Haven't played with it myself, but I believe (anecdotally) that it 
works well.  However that's absolutely no use whatsoever to you in a Solaris 
environment!
Where NFSv4 *does* score over the earlier versions is that you have *other* 
authentication methods available - you don't have to use AUTH_SYS.  In 
particular, as you're integrating all this with AD for unified identity 
management, there are going to be Kerberos tickets floating around the place 
and you could potentially use AUTH_KRB5 instead.  Bingo - problem gone.  OK, so 
nothing in computing is ever quite that simple, but get AUTH_KRB5 working and 
"Bingo - problem gone".  So that might be a solution for you to this problem, 
and potentially simplify your account management as well.

> Essentially our problem generally revolves around ACLs that gives 
> access
to objects for a given group ...

Eurgh - stop right there.
ACLs - work of The Devil! :-)
Potentially ACLs are going to cause you major headaches on NFS mounts anyway
- "The wonderful thing about standards is that there's so many to choose from"; 
NFS ACLs are supposed to be able to be mapped to and fro versus the underlying 
filesystem (whatever ACL mechanism that's using); personally I've never had 
ACLs work correctly on NFS shares of pretty much any underlying filesystem, and 
also be mapped correctly on the client end.  I've also not seen ACLs work 
consistently and reliably with Samba (and I believe there were a couple of 
recent threads on that exac

[Samba] Samba4 LDAP Integration with Asterisk

[Victor Adsuar Abaldea]

Hi,

I am turning crazy. I try to integrate Asterisk 11.5.1 into Samba4 LDAP,
but when I import the ldif file from contrib directory I get this error.

ldbmodify -H /usr/local/samba/private/sam.ldb asterisk.ldif
--option="dsdb:schema update allowed"=true
ERR: (No such object) "objectclass: Cannot add
cn=asterisk,cn=schema,cn=config, parent does not exist!" on DN
cn=asterisk,cn=schema,cn=config at block before line 835
Modify failed after processing 0 records

LDAP and Asterisk are in diferents boxes. Please can someone help me?

Thank you in advance!

 *Victor Adsuar*
*Departamento de Sistemas*
*Teralco Tecnologías Informáticas*
vads...@teralco.com
www.teralco.com

*AVISO LEGAL:
Este mensaje se dirige exclusivamente a su destinatario y puede contener
información reservada y/o CONFIDENCIAL. Si Vd. no es el destinatario
original no está autorizado a copiar o distribuir esta comunicación a
ninguna otra persona. Si ha recibido este mensaje por error, le rogamos nos
lo comunique inmediatamente por esta misma vía y proceda a su borrado. **
Gracias**.*


*DISCLAIMER:
This message is intended exclusively for its addressee and may contain
information that is CONFIDENTIAL and protected by professional privilege.
If you are not the intended recipient you are hereby notified that any
dissemination, copy or disclosure of this communication is strictly
prohibited by law. If this message has been received in error, please
immediately notify us via e-mail and delete it. **Thank** you.*

*
*

*
*

*Antes de imprimir este email piense bien si es necesario hacerlo.*

*Cosider your environmental responsibility before printing this enail*
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Re: [Samba] primary GID based access for user in 16 supplementary groups

[Tris Mabbs]

Hiya Adam,

> We have not seen any issue with primary group not matching file/directory
group owner - but I will look out for this in future.  

Yes, it was a bit of an obscure one to track down, and I'm still not
convinced I've got to the bottom of it - we have a working solution now and
that's where I had to stop poking around.  Thought I'd mention it though in
case it applied in your case.

> We are using NFSv4 but as I understood it this still uses AUTH_SYS
authentication method by default and this is what prevents us moving to >16
groups. ...

Well yes, and no.
Using AUTH_SYS will trip the 16 group limit problem, yes.  That's part of
the definition for NFS defined in RFC - that's
where the 16 group limit comes from and it's not tuneable.
Were you to be using Linux, there's a "magic" hack which gets around this,
by ignoring the group list supplied by NFS and looking up the membership for
itself.  Haven't played with it myself, but I believe (anecdotally) that it
works well.  However that's absolutely no use whatsoever to you in a Solaris
environment!
Where NFSv4 *does* score over the earlier versions is that you have *other*
authentication methods available - you don't have to use AUTH_SYS.  In
particular, as you're integrating all this with AD for unified identity
management, there are going to be Kerberos tickets floating around the place
and you could potentially use AUTH_KRB5 instead.  Bingo - problem gone.  OK,
so nothing in computing is ever quite that simple, but get AUTH_KRB5 working
and "Bingo - problem gone".  So that might be a solution for you to this
problem, and potentially simplify your account management as well.

> Essentially our problem generally revolves around ACLs that gives access
to objects for a given group ...

Eurgh - stop right there.
ACLs - work of The Devil! :-)
Potentially ACLs are going to cause you major headaches on NFS mounts anyway
- "The wonderful thing about standards is that there's so many to choose
from"; NFS ACLs are supposed to be able to be mapped to and fro versus the
underlying filesystem (whatever ACL mechanism that's using); personally I've
never had ACLs work correctly on NFS shares of pretty much any underlying
filesystem, and also be mapped correctly on the client end.  I've also not
seen ACLs work consistently and reliably with Samba (and I believe there
were a couple of recent threads on that exact subject in the support fora,
but don't quote me on that ...).
Now, since you're accessing this using Samba, and Samba works out group
membership based on the AD groups and uses that primarily to control access,
effectively merged with the local filesystem permissions (as I understand it
- I'm not a Samba guru and could be wrong ...), you might have more luck
achieving the equivalent of group-based ACLs by nested group membership in
the AD groups.
As you're using "Quest", I don't know how well that would work - I'm afraid
I've heard of "Quest" but never used it (just Samba/native OS support for AD
integration, oh and "Centrify" ...).  However I don't see why it *wouldn't*
work.
So where you use "setfacl" ("Set F*ck-All", as I tend to think of it ...
Pardon the language - really NOT a fan of ACLs, so many issues ...) to
permit group write to a directory, and one of the groups happens to be
users' primary GID; instead define an AD group ("(Unix) Access ''
resource", or some similarly descriptive name) with however Quest assigns a
GID to that group, then set the group ownership on the objects to the GID of
that group, then include in that group all the other groups to which you're
currently granting access via ACLs.
E.g.:
/someshare/controlled_resource:
ACLs:
Grant R/W access to groups:
users1
users2
...
Instead:
Create AD group "(Unix) Access 'controlled_resource'",
Assign (say) GID 1 to that group,
chgrp 1 /someshare/controlled_resource
chmod g=rwx,g+s /someshare/controlled_resource
Include "users1", "users2", ... in that group.
Same effect, no ACLs, Samba should be happy.  You might need to tweak the
file/directory creation modes masks for Samba, and be careful of the effects
of mapping system (etc.) attributes (which are mapped using Unix permissions
bits), but get the right combination of Samba options and that should work.
If I've understood correctly what you're trying to achieve, that is ...
Of course, nesting groups like that may simplify, or may make more complex,
your group membership issues, but that's not a problem anyway if you move to
AUTH_KRB5 ...

As for your IDMAP cacheing issue - yes, I saw that :-)  IMHO you might not
get a response in this group about that - it looked like a "bit" (ha!) more
of an in-depth technical issue and, if you get no responses here, you might
need to put it into the samba-technical forum - in my experience, the Samb

Re: [Samba] primary GID based access for user in 16 supplementary groups

[Burgess, Adam]

I think I have answered this in my other mail.  There are no mismatches.  Our 
AD backend is via an integration layer so that a UNIX account is essentially an 
AD account anyway and all its attributes and group memberships come from AD.  
The name service resolves all correctly and samba does too in terms of the 
final smbd process context that is created (ie its euid/gid are as you would 
expect and supplementary gid list is too).  

However, the checking open right functions simply ignore the PGID, and this 
seems to give the resulting client access difference (Windows 7 seemingly 
listening to the access denied reply, with XP ignoring it and soldiering on so 
that Samba then actually gives the access) - this a little bit of guessing on 
my part as my debugging is not complete.  I have noticed that the open 
access_mask requested with Windows 7 client is 0x81 while other clients request 
0x20089 or 0x11 for example.


-Original Message-
From: samba-boun...@lists.samba.org [mailto:samba-boun...@lists.samba.org] On 
Behalf Of steve
Sent: 05 September 2013 20:24
To: samba@lists.samba.org
Subject: Re: [Samba] primary GID based access for user in 16 supplementary 
groups

On Thu, 2013-09-05 at 19:45 +0100, Tris Mabbs wrote:

> 5. Are you *absolutely* sure that your idmap back-ends are doing what 
> you thought?

Here's another few cents:
What you are describing is almost certainly mismatched gidNumbers.
Depending on where the SID to GID mapping came from it will be different. Most 
certainly not what you want.

So: Avoid anything other than the ad backend like the plague.

Add gidNumber to the DN of the group and uidNumber and gidNumber to the DN of 
the user. Use sssd to pull that info from AD on _anything_ unix be it the DC, 
the file server or a solaris/linux client.
HTH
Steve


--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Re: [Samba] primary GID based access for user in 16 supplementary groups

[Burgess, Adam]

Thanks Tris.

We have not seen any issue with primary group not matching file/directory group 
owner - but I will look out for this in future.  

We are using NFSv4 but as I understood it this still uses AUTH_SYS 
authentication method by default and this is what prevents us moving to >16 
groups.  We do have such memberships and struggle enough already without trying 
to reduce this to 15 in order to work around this particular issue.

Essentially our problem generally revolves around ACLs that gives access to 
objects for a given group that happens to be the primary group of many accounts 
because there are so many accounts that must belong to it, (we are also not 
prepared to attempt splitting the group into multiple ones and allocating the 
users between them as this makes for even more management headaches doing this 
allocation and then having to add all of these groups to the objects ACLs).

Our IDMAP backend works well - that much I am confident of.  The backend is 
itself the Quest ID Mapper that uses Quest Authentication Services integration 
to AD - we are not actually using UNIX attributes directly on the AD objects 
but that is another story.  Suffice to say that SID-UID and SID-GID mappings in 
both directions all seems to work correctly for all AD user/group accounts that 
are setup be shall we say "UNIX enabled".  In our UNIX environment AD is the 
backend for NSS (name services switch) - ie we have single identity management 
directory between Windows and UNIX environments  (thus we can't just remove 
some AD memberships to suit Samba based access). 

There is a another problem with the Samba IDMAP operations which is not an 
issue of the backend but of the caching method and general SID-to-UNIX-ID 
lookup method.  I have posted about that separately.  Independent of that issue 
we need to know how Samba is designed to work in the case described before we 
can say whether Windows 7 client of Windows XP is working correctly, and then 
look for potential workarounds/fixes.  I myself would like to see a config 
switch to choose between implicit UNIX PGID membership and not.  SMBD should 
also be able to programmatically not add in an actual supplementary group 
membership from the UNIX security token if this is the primary GID of the 
account (this prevent the issue of blowing any limit).

Adam

-Original Message-
From: Tris Mabbs [mailto:tm-samba201...@firstgrade.co.uk] 
Sent: 05 September 2013 19:46
To: Burgess, Adam; samba@lists.samba.org
Subject: RE: [Samba] primary GID based access for user in 16 supplementary 
groups

Hiya Adam,

We too have had no end of problems with this sort of issue using Samba on 
Solaris (11 in our case) running against AD and using (predominantly) "Windows 
7" clients.

Someone with more knowledge of the Samba internals can probably answer your 
questions about what is the correct behaviour, and why this is happening.
However if you're like me, it's more urgent actually to have something working 
than to know the precise details of implementation of some rather nasty 
protocols ...

So - my $0.02, in case it's of any use.

1. For whatever reason, Samba does not play nicely when the GID of an object 
does not match the account's primary GID.  One easy way (we've found anyway
- YMMV) to demonstrate this is to locate any "$RECYCLE.BIN" directory for a 
user, change the GID to that of another group of which the user is a member, 
then open the desktop "Recycle Bin" - you'll get a whinge about "The recycle 
bin on \\server\path\to\$RECYCLE.BIN is corrupted.  Do you want to empty the 
Recycle Bin for this drive?" (or words to that effect).
2. Things work much more smoothly when the AD group membership for the user 
includes the primary GID (and that's set as the primary group name in the Unix 
attributes for the account).  It's not a cure for all ills, but it did clear up 
a number of similar problems we had.
3. That, as you pointed out, may well break the Solaris internal limit of 16 
groups.  However, is that really a problem for you?  More than 16 will break 
NFSv3, but if you're not using NFSv3 then the worst that will happen is you'll 
get whinged at at boot time and that's it.  Depending on your version of 
Solaris, there is an internal hard-coded kernel limit; as of OpenSolaris 
"snv_129" it was increased from 32 (the limit you may well have) to 1024, but 
if you're not over the limit (without including the primary GID) at 16 then 32 
will easily be sufficient for you anyway.  We run with "set ngroups_max = 1024" 
in our "/etc/system" (not that we need that many, but
...) and things generally troll along smoothly as a result.  Oh, depending
(again) on which version you're running - if you've patched your Solaris 
systems to a stage where they use Grub, don't forget the obligatory "bootadm 
update-archive", but I'm sure you know that already :-).
4. You've not gone into details of when (or even if) you might need to use 
different GIDs on directories (or

[Samba] Problem with kerberos and GPO

[Stéphane PURNELLE]

Hi,

I have problem with GPO and dns/kerberos resolution

I do a samba -i -d3 to a log file and started on client: gpupdate /force:

lpcfg_load: refreshing parameters from /srv/samba/etc/smb.conf
params.c:pm_process() - Processing configuration file 
"/srv/samba/etc/smb.conf"
samba version 4.1.0rc2 started.
Copyright Andrew Tridgell and the Samba Team 1992-2013
...
ldb_wrap open of privilege.ldb
samba: using 'standard' process model
...
ldb_wrap open of secrets.ldb
ldb_wrap open of idmap.ldb
dreplsrv_partition[CN=Configuration,DC=cormandom,DC=int-corman,DC=be] 
loaded
dreplsrv_partition[CN=Schema,CN=Configuration,DC=cormandom,DC=int-corman,DC=be] 
loaded
dreplsrv_partition[DC=cormandom,DC=int-corman,DC=be] loaded
dreplsrv_partition[DC=DomainDnsZones,DC=cormandom,DC=int-corman,DC=be] 
loaded
dreplsrv_partition[DC=ForestDnsZones,DC=cormandom,DC=int-corman,DC=be] 
loaded
/usr/local/samba/sbin/smbd: smbd version 4.1.0rc2 started.
/usr/local/samba/sbin/smbd: Copyright Andrew Tridgell and the Samba Team 
1992-2013
/usr/local/samba/sbin/smbd: INFO: Current debug levels:
...
kccsrv_partition[CN=Configuration,DC=cormandom,DC=int-corman,DC=be] loaded
/usr/local/samba/sbin/smbd:   scavenger: 5
kccsrv_partition[CN=Schema,CN=Configuration,DC=cormandom,DC=int-corman,DC=be] 
loaded
kccsrv_partition[DC=DomainDnsZones,DC=cormandom,DC=int-corman,DC=be] 
loaded
/usr/local/samba/sbin/smbd:   dns: 5
kccsrv_partition[DC=ForestDnsZones,DC=cormandom,DC=int-corman,DC=be] 
loaded
/usr/local/samba/sbin/smbd:   ldb: 5
/usr/local/samba/sbin/smbd: doing parameter log file = 
/var/log/samba/%U.%m.log
/usr/local/samba/sbin/smbd: doing parameter unix charset = ISO-8859-15
/usr/local/samba/sbin/smbd: doing parameter dos charset = ISO-8859-15
/usr/local/samba/sbin/smbd: pm_process() returned Yes
/usr/local/samba/sbin/smbd: get_current_groups: user is in 1 groups: 0
/usr/local/samba/sbin/smbd: Registering messaging pointer for type 2 - 
private_data=(nil)
/usr/local/samba/sbin/smbd: Registering messaging pointer for type 9 - 
private_data=(nil)
/usr/local/samba/sbin/smbd: Registered MSG_REQ_POOL_USAGE
/usr/local/samba/sbin/smbd: Registering messaging pointer for type 11 - 
private_data=(nil)
/usr/local/samba/sbin/smbd: Registering messaging pointer for type 12 - 
private_data=(nil)
/usr/local/samba/sbin/smbd: Registered MSG_REQ_DMALLOC_MARK and 
LOG_CHANGED
/usr/local/samba/sbin/smbd: Registering messaging pointer for type 1 - 
private_data=(nil)
/usr/local/samba/sbin/smbd: Registering messaging pointer for type 5 - 
private_data=(nil)
/usr/local/samba/sbin/smbd: lp_load_ex: refreshing parameters
/usr/local/samba/sbin/smbd: Freeing parametrics:
/usr/local/samba/sbin/smbd: Initialising global parameters
/usr/local/samba/sbin/smbd: rlimit_max: increasing rlimit_max (1024) to 
minimum Windows limit (16384)
/usr/local/samba/sbin/smbd: params.c:pm_process() - Processing 
configuration file "/srv/samba/etc/smb.conf"
/usr/local/samba/sbin/smbd: Processing section "[global]"
/usr/local/samba/sbin/smbd: doing parameter workgroup = CORMAN
/usr/local/samba/sbin/smbd: doing parameter realm = 
cormandom.int-corman.be
/usr/local/samba/sbin/smbd: doing parameter netbios name = ADMIN01
/usr/local/samba/sbin/smbd: doing parameter server role = active directory 
domain controller
/usr/local/samba/sbin/smbd: doing parameter server services = s3fs, rpc, 
nbt, wrepl, ldap, cldap, kdc, drepl, winbind, ntp_signd, kcc
/usr/local/samba/sbin/smbd: doing parameter idmap_ldb:use rfc2307 = yes
/usr/local/samba/sbin/smbd: doing parameter acl:search = no
/usr/local/samba/sbin/smbd: doing parameter ntp signd socket directory = 
/srv/samba/ntp_signd/
/usr/local/samba/sbin/smbd: doing parameter pid directory = /var/run/samba
/usr/local/samba/sbin/smbd: doing parameter max log size = 5
/usr/local/samba/sbin/smbd: doing parameter log level = 5
/usr/local/samba/sbin/smbd: INFO: Current debug levels:
/usr/local/samba/sbin/smbd:   all: 5
...
/usr/local/samba/sbin/smbd: doing parameter log file = 
/var/log/samba/%U.%m.log
/usr/local/samba/sbin/smbd: doing parameter unix charset = ISO-8859-15
/usr/local/samba/sbin/smbd: doing parameter dos charset = ISO-8859-15
/usr/local/samba/sbin/smbd: Processing section "[netlogon]"
/usr/local/samba/sbin/smbd: doing parameter path = 
/srv/samba/sysvol/int-corman.be/scripts
/usr/local/samba/sbin/smbd: doing parameter read only = No
/usr/local/samba/sbin/smbd: Processing section "[sysvol]"
/usr/local/samba/sbin/smbd: doing parameter path = /srv/samba/sysvol
/usr/local/samba/sbin/smbd: doing parameter read only = No
/usr/local/samba/sbin/smbd: Processing section "[homes]"
/usr/local/samba/sbin/smbd: doing parameter comment = Repertoire Home
/usr/local/samba/sbin/smbd: doing parameter path = /rsrv/vol1/home/%U
/usr/local/samba/sbin/smbd: doing parameter force user = %U
/usr/local/samba/sbin/smbd: doing parameter read only = No
/usr/local/samba/sbin/smbd: doing parameter directory mask = 0700
/usr/local/samba/sbin/smbd: doing parameter browseabl

Re: [Samba] dns update failt (kerberos)

[Thomas Zeitinger]

Ah, ok. Your are right:

root@linsrv:/usr/local/samba/private# klist -e -t -k
/usr/local/samba/private/secrets.keytab
Keytab name: FILE:/usr/local/samba/private/secrets.keytab
KVNO Timestamp   Principal
 ---
--
   1 2013-08-16 12:49:52 HOST/linsrv@DOMAIN.LOCAL (des-cbc-crc)
   1 2013-08-16 12:49:52 HOST/linsrv.domain.local@DOMAIN.LOCAL
(des-cbc-crc)
   1 2013-08-16 12:49:52 LINSRV$@DOMAIN.LOCAL (des-cbc-crc)
   1 2013-08-16 12:49:52 HOST/linsrv@DOMAIN.LOCAL (des-cbc-md5)
   1 2013-08-16 12:49:52 HOST/linsrv.domain.local@DOMAIN.LOCAL
(des-cbc-md5)
   1 2013-08-16 12:49:52 LINSRV$@DOMAIN.LOCAL (des-cbc-md5)
   1 2013-08-16 12:49:52 HOST/linsrv@DOMAIN.LOCAL (arcfour-hmac)
   1 2013-08-16 12:49:52 HOST/linsrv.domain.local@DOMAIN.LOCAL
(arcfour-hmac)
   1 2013-08-16 12:49:52 LINSRV$@DOMAIN.LOCAL (arcfour-hmac)
   1 2013-08-16 12:49:52 HOST/linsrv@DOMAIN.LOCAL (aes128-cts-hmac-sha1-96)
   1 2013-08-16 12:49:52 HOST/linsrv.domain.local@DOMAIN.LOCAL
(aes128-cts-hmac-sha1-96)
   1 2013-08-16 12:49:52 LINSRV$@DOMAIN.LOCAL (aes128-cts-hmac-sha1-96)
   1 2013-08-16 12:49:52 HOST/linsrv@DOMAIN.LOCAL (aes256-cts-hmac-sha1-96)
   1 2013-08-16 12:49:52 HOST/linsrv.domain.local@DOMAIN.LOCAL
(aes256-cts-hmac-sha1-96)
   1 2013-08-16 12:49:52 LINSRV$@DOMAIN.LOCAL (aes256-cts-hmac-sha1-96)


On 2013-09-05 18:07, Burgess, Adam wrote:
> They will likely be different entries with different kvno and encryption type 
> combinations.  Not sure what syntax your klist uses but -e option may give 
> you the encryption type output for example.
>
>
> Adam
>
> -Original Message-
> From: samba-boun...@lists.samba.org [mailto:samba-boun...@lists.samba.org] On 
> Behalf Of Thomas Zeitinger
> Sent: 05 September 2013 16:42
> To: samba@lists.samba.org
> Subject: Re: [Samba] dns update failt (kerberos)
>
> Hey!
>
> I found another interessting fact:
>
> samba_dnsupdate --verbose --all-names -d 10
>
> shows me:
>
> [...]
> privateKeytab: secrets.keytab
> [...]
>
> So I tried
>
> root@linsrv:~# klist -t -k /usr/local/samba/private/secrets.keytab
> Keytab name: FILE:/usr/local/samba/private/secrets.keytab
> KVNO Timestamp   Principal
>  ---
> --
>1 2013-08-16 12:49:52 HOST/linsrv@DOMAIN.LOCAL  
>1 2013-08-16 12:49:52 HOST/linsrv.domain.local@DOMAIN.LOCAL
>1 2013-08-16 12:49:52 LINSRV$@DOMAIN.LOCAL
>1 2013-08-16 12:49:52 HOST/linsrv@DOMAIN.LOCAL  
>1 2013-08-16 12:49:52 HOST/linsrv.domain.local@DOMAIN.LOCAL
>1 2013-08-16 12:49:52 LINSRV$@DOMAIN.LOCAL
>1 2013-08-16 12:49:52 HOST/linsrv@DOMAIN.LOCAL  
>1 2013-08-16 12:49:52 HOST/linsrv.domain.local@DOMAIN.LOCAL
>1 2013-08-16 12:49:52 LINSRV$@DOMAIN.LOCAL
>1 2013-08-16 12:49:52 HOST/linsrv@DOMAIN.LOCAL  
>1 2013-08-16 12:49:52 HOST/linsrv.domain.local@DOMAIN.LOCAL
>1 2013-08-16 12:49:52 LINSRV$@DOMAIN.LOCAL
>1 2013-08-16 12:49:52 HOST/linsrv@DOMAIN.LOCAL  
>1 2013-08-16 12:49:52 HOST/linsrv.domain.local@DOMAIN.LOCAL
>1 2013-08-16 12:49:52 LINSRV$@DOMAIN.LOCAL
>
>
> Is it a problem that the host is 5 times in the secret.keytab?
>
> How can I verify that?

-- 
Thomas Zeitinger
Kundenbetreuung

IT-Quadrat   EDV Dienstleistungs- und Handels GmbH
Krongasse 8/2 A-1050 Wien
Tel: +43 (1) 311 44 00 - 10
Fax: +43 (1) 311 44 00 - 90
thomas.zeitin...@it2.at
www.it2.at

FN 287345t
UID ATU63123113


-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Re: [Samba] Samba4/Windows DNS replication and administration issue

[steve]

On Thu, 2013-09-05 at 20:39 -0700, Pete Storkey wrote:

> 
> I have tried manually recreating dns.keytab:
> 
> # samba-tool domain exportkeytab --principal=DNS/server.domain.com 
> /var/lib/samba/private/dns.keytab
> # samba-tool domain exportkeytab --principal=DNS/windowsserver.domain.com 
> /var/lib/samba/private/dns.keytab
> 

That syntax seems wrong.
# samba-tool domain exportkeytab /path/to/dns.keytab
--principal=server1.your.domain
 

> The contents of dns.keytab are as follows:
> 
> # ktutil
> ktutil:  read_kt /var/lib/samba/private/dns.keytab
> ktutil:  list
> slot KVNO Principal
>   
> -
>   11  DNS/server.domain@domain.com
>   21  DNS/server.domain@domain.com
>   31  DNS/server.domain@domain.com
>   4   31 DNS/windowsserver.domain@domain.com
>   5   31 DNS/windowsserver.domain@domain.com
>   6   31 DNS/windowsserver.domain@domain.com
>   7   31 DNS/windowsserver.domain@domain.com
> 
> The problem persists after recreating dns.keytab and restarting Samba and 
> Bind daemons.
> 
> Is this the correct way to generate the dns.keytab? Is there anything I'm 
> missing?

Maybe you didn't recreate the keytab? Look for the timestamp:
klist -kte /path/to/dns.keytab

The only difference I can see with our keytab is that we have:
DNS/fqdn@REALM
and
short-hostname@REALM

Maybe this isn't a keytab issue?
HTH
Steve


-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba