Nabble - Samba

DCE_STYLE, AES and sequence numbers

2008-07-24T22:16:54Z

The documentation in MS-KILE 3.4.5.1 on DCE_STYLE is very terse, and
fails to clarify a few points, one of which is preventing
interoperability with Windows Vista.

The client MUST generate an additional AP reply message exactly as the server would ([RFC4120]
section 3.2.4) as the final message to send to the server. In GSS terms, the client must return
success and a message to the server. It is up to the application to deliver the message to the
server.

The server MUST receive the additional AP reply message and verify that the message is
constructed correctly ([RFC4120] section 3.2.5).

What is unclear here is how the sequence numbers, exchanged in this
message, are expected to be updated. For example, with a WinXP clients,
and arcfour-hmac-md5 encryption, the sequence number (as maintained by
the client, and seen on the server) is unaffected by the receipt of this
extra message.

In Heimdal's implementation here, we reset the sequence numbers after
verifying the AP_REP at line 690.

http://git.samba.org/?p=samba.git;a=blob;f=source/heimdal/lib/gssapi/krb5/accept_sec_context.c;h=73b93ceba4c6bb472c546afd52981bcf13051173;hb=v4-0-test

However, when GSSAPI CFX is used, and therefore an AES key is negotiated
by a Windows Vista client to a Samba4 server, the client seems to
require that the remote (from the server's persective) sequence number
be increased by 1.

(ie, adding 1 to r_seq_number at like 690 allows the next gss_unwrap to
match the expected sequence number correctly, in the DRSUAPI bind
portion of a Vista SP1 domain join).

Simiarly, you will note in line 606, that we must disable timestamp verification.

While the client code (like 663) is comparatively sane...
http://git.samba.org/?p=samba.git;a=blob;f=source/heimdal/lib/gssapi/krb5/init_sec_context.c;h=c455a5dc8b7246c0c8e795206be5b9c3db114cb8;hb=v4-0-test

It seems that this is more than a simple role reversal, and the docs
need to be expanded to clarify this.

Thanks,

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

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

signature.asc (196 bytes) Download Attachment

From forum: Samba - cifs-protocol

Re: (MythTV) LIRC + TView99 card - IR problem

2008-07-24T21:39:53Z

G'Day Andrew

I'm not the bearer of good news i'm afraid, my first attempt with
Mythtv was with on of these tuner cards and I never managed to get it
working even as a tuner. After many attempts, some great help from
various list members and a deal of frustration, I just bought a DVB device.

For what it's worth I aquired via E-Bay some time ago a Micro$oft MCE
remote which has a nice feature of incorporating 2 programmable ir
senders as will as an ir receiver which allows control of the TV as well
as Myth with the one remote. I use Mythbuntu now and this device
installed itself as part of the Mythbuntu installation process and apart
from a couple of errors in the in the LIRCD file, worked without
further intervention. Prior to that I was just using a simple serial
remote which also worked fine for Myth.

Hope you have better luck that I did but if all else fails there are
some fairly cheap solutions available to you as alternatives.

Regards

Ian Bardsley

Andrew Smith wrote:

> Hi List,
>
> Firstly, I have to say that Myth is a kick-arse bit of open source.
> All of my hats are off to those who've contributed to it.
>
> I have a TView99 Analogue tuner card from about a billion years ago
> that I'd like to use as my IR receiver. My main tuner is a Twin HD
> card (without IR), I threw the TView card in cause I had it, would
> like to tune Analogue and need IR. I'm hoping someone on the list
> happens to have one of these cards working, or can steer me on
> diagnosis of the problem.
>
> My Distro is MythDora (cause it's quick). I have the card tuning fine
> - bttv auto detects the correct card type, and the IR function seems
> to be correctly found and provides /dev/input/event6 for me to use
> with irrecord (irrecord -H dev/input -d /dev/input/event6 lircd.conf)
>
> The issue is that irrecord times out after 10 seconds with:
> Hold down an arbitrary button.
> <10 secs>
> irrecord: gap not found, can't continue
> irrecord: closing '/dev/input/event6'
>
> I'm thinking it might even be a hardware problem - I'm pretty sure I'm
> using the correct IR lead (white stereo 3.5mm plug) - that's where I'm
> hoping someone has one and can confirm. I haven't located the
> original remote, but have been hoping that at least one of the others
> I've tried (including a Hauppauge x50 remote) should've shown up
> something.
>
> From what I understand, irrecord is talking directly to the
> module/card, so lircd isn't running or configured at this point.
>
> Other output below.
>
> An help/pointers appreciated!
> Thanks
> Andrew
>
> dmesg:
>
> bttv: Bt8xx card found (0).
> ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 16 (level, low) -> IRQ 16
> bttv0: Bt878 (rev 2) at 0000:04:00.0, irq: 16, latency: 64, mmio:
> 0xd8001000
> bttv0: detected: (Askey Magic/others) TView99 CPH06x [card=38], PCI
> subsystem ID is 144f:3000
> bttv0: using: Askey CPH06X TView99 [card=38,autodetected]
> bttv0: gpio: en=00000000, out=00000000 in=00ffefff [init]
> bttv0: tuner type=1
> bttv0: i2c: checking for MSP34xx @ 0x80... not found
> bttv0: i2c: checking for TDA9875 @ 0xb0... not found
> bttv0: i2c: checking for TDA7432 @ 0x8a... not found
> All bytes are equal. It is not a TEA5767
> tuner 1-0060: chip found @ 0xc0 (bt878 #0 [sw])
> tuner-simple 1-0060: type set to 1 (Philips PAL_I (FI1246 and
> compatibles))
> tuner 1-0060: type set to Philips PAL_I (FI12
> tuner-simple 1-0060: type set to 1 (Philips PAL_I (FI1246 and
> compatibles))
> tuner 1-0060: type set to Philips PAL_I (FI12
> bttv0: registered device video0
> bttv0: registered device vbi0
> bttv0: PLL: 28636363 => 35468950 .. ok
> input: bttv IR (card=38) as /class/input/input6
> bt878: AUDIO driver version 0.0.0 loaded
> bt878: Bt878 AUDIO function found (0).
> ACPI: PCI Interrupt 0000:04:00.1[A] -> GSI 16 (level, low) -> IRQ 16
> bt878_probe: card id=[0x3000144f], Unknown card.
>
> cat /proc/bus/input/devices:
>
> I: Bus=0001 Vendor=144f Product=3000 Version=0001
> N: Name="bttv IR (card=38)"
> P: Phys=pci-0000:04:00.0/ir0
> S: Sysfs=/class/input/input6
> U: Uniq=
> H: Handlers=kbd event6
> B: EV=100003
> B: KEY=10afc336 2150a48 0 0 0 404 80010000 190 4801 1e0000 4400 100000
> 10000ffc
>
>

--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux

From forum: Samba - linux

Re: Vista CFX join and 'out of order' GSSAPI messages

2008-07-24T21:38:07Z

On Tue, 2008-07-22 at 19:16 +0100, Love Hörnquist Åstrand wrote:
> Hello Andrew,
>
> The DCE-STYLE patches where from metze (I think)
>
> Also, just to confuse us, the seq number might be diffrent for RC4 and
> AES

It certainly appears that way. Patched to allow the sequence number to
match for Vista, it fails to accept a join from WinXP.

Andrew Bartlett

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

signature.asc (196 bytes) Download Attachment

From forum: Samba - samba-technical

Re: IPv6 Australia?

2008-07-24T21:28:10Z

Robert Edwards wrote:

> Michael Still wrote:
>> Robert Edwards wrote:
>>
>>> We'll wait and see how "strictly" adhered to the hierarchical routing
>>> scheme really ends up. I am not so sure. The so-called "massive routing
>>> tables" of IPv4 aren't all that massive these days, with CIDR and other
>>> policies having reduced the potential number of entries. In any case,
>>> it is not an issue for most people and those who do care have solved
>>> it or are using IPv6 as their backbone routing infrastructure.
>>
>> DFZ routers currently seem to carry about 2.2 BGP entries for the IPv4
>> Internet. It would be interesting to know how much route aggregation
>> helps reduce that number.
>>
>> Mikal
>
> 2.2 seems a little on the low side, plus I am not sure how they can have
> 0.2 of a routing table entry... :) Is it 2.2 million?

Sorry, yes. Let's go with that.

Mikal

--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux

From forum: Samba - linux

Re: IPv6 Australia?

2008-07-24T21:12:09Z

Michael Still wrote:

> Robert Edwards wrote:
>
>> We'll wait and see how "strictly" adhered to the hierarchical routing
>> scheme really ends up. I am not so sure. The so-called "massive routing
>> tables" of IPv4 aren't all that massive these days, with CIDR and other
>> policies having reduced the potential number of entries. In any case,
>> it is not an issue for most people and those who do care have solved
>> it or are using IPv6 as their backbone routing infrastructure.
>
> DFZ routers currently seem to carry about 2.2 BGP entries for the IPv4
> Internet. It would be interesting to know how much route aggregation
> helps reduce that number.
>
> Mikal

2.2 seems a little on the low side, plus I am not sure how they can have
0.2 of a routing table entry... :) Is it 2.2 million?

Bob Edwards.
--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux

From forum: Samba - linux

DO NOT REPLY [Bug 5407] hlink.c:480: finish_hard_link: Assertion `flist != ((void *)0)' failed.

2008-07-24T20:48:01Z

https://bugzilla.samba.org/show_bug.cgi?id=5407

wayned@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
Version|3.0.2 |3.0.3

------- Comment #4 from wayned@... 2008-07-24 22:48 CST -------
Good to hear! We'll mark this one as fixed in 3.0.3, then. Thanks!

--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

From forum: Samba - rsync

DCE/RPC PFC_SUPPORT_HEADER_SIGN not optional

2008-07-24T20:36:19Z

MS-RPCE 3.3.1.5.2.2 implies that the PFC_SUPPORT_HEADER_SIGN bit in the
RPC bind messages negotiates optional support for header signing.
however, this is not the case - the client (Vista SP1 in this case) will
sign the RPC headers if the target security mechanism supports it.

(ie, original style NTLM has unsigned headers, NTLM2 session security
signs them, GSSAPI does not, unless using AES per MS-KILE 3.4.5.4.1)

Therefore the documentation for this extension should be rewritten to
indicate that this is an informative bit, not a negotiated flag.

(And while painful to me, if this were to be a real negotiation, the
attacker this feature is expected to disrupt would be able to simply
turn it off).

Thanks,

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

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

signature.asc (196 bytes) Download Attachment

From forum: Samba - cifs-protocol

Rsync 3.0.4pre1 released

2008-07-24T20:28:20Z

Rsync version 3.0.4pre1 is now available for release testing. This is
a bug-fix release with the only enhancement being the adding of a way
to interact with an overly-restrictive server that refuses rsync's
behind-the-scenes use of the -e option.

Please test this new release and send email to the rsync mailing list
with any questions, comments, or bug reports.

To see a full summary of the changes since 3.0.3, visit this link:

http://rsync.samba.org/ftp/rsync/src-previews/rsync-3.0.4pre1-NEWS

You can download the source tar file and its signature from here:

http://rsync.samba.org/ftp/rsync/src-previews/rsync-3.0.4pre1.tar.gz
http://rsync.samba.org/ftp/rsync/src-previews/rsync-3.0.4pre1.tar.gz.asc

The patches directory is now in a separate tar file (for those that want
one or more of the patches):

http://rsync.samba.org/ftp/rsync/src-previews/rsync-patches-3.0.4pre1.tar.gz
http://rsync.samba.org/ftp/rsync/src-previews/rsync-patches-3.0.4pre1.tar.gz.asc

See the rsync website for other download methods, including diffs, etc.:

http://rsync.samba.org/

..wayne..

--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

signature.asc (196 bytes) Download Attachment

From forum: Samba - rsync

Rsync 3.0.4pre1 released

2008-07-24T20:28:20Z

Rsync version 3.0.4pre1 is now available for release testing. This is
a bug-fix release with the only enhancement being the adding of a way
to interact with an overly-restrictive server that refuses rsync's
behind-the-scenes use of the -e option.

Please test this new release and send email to the rsync mailing list
with any questions, comments, or bug reports.

To see a full summary of the changes since 3.0.3, visit this link:

http://rsync.samba.org/ftp/rsync/src-previews/rsync-3.0.4pre1-NEWS

You can download the source tar file and its signature from here:

http://rsync.samba.org/ftp/rsync/src-previews/rsync-3.0.4pre1.tar.gz
http://rsync.samba.org/ftp/rsync/src-previews/rsync-3.0.4pre1.tar.gz.asc

The patches directory is now in a separate tar file (for those that want
one or more of the patches):

http://rsync.samba.org/ftp/rsync/src-previews/rsync-patches-3.0.4pre1.tar.gz
http://rsync.samba.org/ftp/rsync/src-previews/rsync-patches-3.0.4pre1.tar.gz.asc

See the rsync website for other download methods, including diffs, etc.:

http://rsync.samba.org/

..wayne..

_______________________________________________
rsync-announce mailing list
rsync-announce@...
https://lists.samba.org/mailman/listinfo/rsync-announce

signature.asc (196 bytes) Download Attachment

From forum: Samba - rsync-announce

Re: IPv6 Australia?

2008-07-24T20:26:11Z

Robert Edwards wrote:

> We'll wait and see how "strictly" adhered to the hierarchical routing
> scheme really ends up. I am not so sure. The so-called "massive routing
> tables" of IPv4 aren't all that massive these days, with CIDR and other
> policies having reduced the potential number of entries. In any case,
> it is not an issue for most people and those who do care have solved
> it or are using IPv6 as their backbone routing infrastructure.

DFZ routers currently seem to carry about 2.2 BGP entries for the IPv4
Internet. It would be interesting to know how much route aggregation
helps reduce that number.

Mikal
--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux

From forum: Samba - linux

DO NOT REPLY [Bug 5407] hlink.c:480: finish_hard_link: Assertion `flist != ((void *)0)' failed.

2008-07-24T19:38:56Z

https://bugzilla.samba.org/show_bug.cgi?id=5407

------- Comment #3 from brian_lindholm@... 2008-07-24 21:39 CST -------
I've not seen the error since I upgraded to rsync-3.0.3pre1. But given the
intermittent nature of the error (1 out of 20 runs or so), I didn't have much
opportunity to observe the problem before I upgraded to 3.0.3pre2. And not
much time on pre2 before upgrading to 3.0.3-final.

It seems likely that the problem was fixed during the 3.0.3 development cycle,
but I can't say for sure. Version 3.0.3 has behaved flawlessly for me, without
even a single errant run, but it's only been a month. I've done perhaps a
hundred rsync runs during that time.

[Hmmm... If the bug were still present with a 5% probability of manifesting
per run, there's less than a 0.6% chance that I'd get as far as 100 runs
without seeing it. That's pretty darned unlikely. Perhaps we should close
this bugzilla case out as "fixed". And in the unlikely event that I ever see
it again, I'll try the extra options on 3.1.0 as you suggest.]

--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

From forum: Samba - rsync

(MythTV) LIRC + TView99 card - IR problem

2008-07-24T19:34:49Z

Hi List,

Firstly, I have to say that Myth is a kick-arse bit of open source. All
of my hats are off to those who've contributed to it.

I have a TView99 Analogue tuner card from about a billion years ago that
I'd like to use as my IR receiver. My main tuner is a Twin HD card
(without IR), I threw the TView card in cause I had it, would like to
tune Analogue and need IR. I'm hoping someone on the list happens to
have one of these cards working, or can steer me on diagnosis of the
problem.

My Distro is MythDora (cause it's quick). I have the card tuning fine -
bttv auto detects the correct card type, and the IR function seems to be
correctly found and provides /dev/input/event6 for me to use with
irrecord (irrecord -H dev/input -d /dev/input/event6 lircd.conf)

The issue is that irrecord times out after 10 seconds with:
Hold down an arbitrary button.
<10 secs>
irrecord: gap not found, can't continue
irrecord: closing '/dev/input/event6'

I'm thinking it might even be a hardware problem - I'm pretty sure I'm
using the correct IR lead (white stereo 3.5mm plug) - that's where I'm
hoping someone has one and can confirm. I haven't located the original
remote, but have been hoping that at least one of the others I've tried
(including a Hauppauge x50 remote) should've shown up something.

From what I understand, irrecord is talking directly to the
module/card, so lircd isn't running or configured at this point.

Other output below.

An help/pointers appreciated!
Thanks
Andrew

dmesg:

bttv: Bt8xx card found (0).
ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 16 (level, low) -> IRQ 16
bttv0: Bt878 (rev 2) at 0000:04:00.0, irq: 16, latency: 64, mmio: 0xd8001000
bttv0: detected: (Askey Magic/others) TView99 CPH06x [card=38], PCI
subsystem ID is 144f:3000
bttv0: using: Askey CPH06X TView99 [card=38,autodetected]
bttv0: gpio: en=00000000, out=00000000 in=00ffefff [init]
bttv0: tuner type=1
bttv0: i2c: checking for MSP34xx @ 0x80... not found
bttv0: i2c: checking for TDA9875 @ 0xb0... not found
bttv0: i2c: checking for TDA7432 @ 0x8a... not found
All bytes are equal. It is not a TEA5767
tuner 1-0060: chip found @ 0xc0 (bt878 #0 [sw])
tuner-simple 1-0060: type set to 1 (Philips PAL_I (FI1246 and compatibles))
tuner 1-0060: type set to Philips PAL_I (FI12
tuner-simple 1-0060: type set to 1 (Philips PAL_I (FI1246 and compatibles))
tuner 1-0060: type set to Philips PAL_I (FI12
bttv0: registered device video0
bttv0: registered device vbi0
bttv0: PLL: 28636363 => 35468950 .. ok
input: bttv IR (card=38) as /class/input/input6
bt878: AUDIO driver version 0.0.0 loaded
bt878: Bt878 AUDIO function found (0).
ACPI: PCI Interrupt 0000:04:00.1[A] -> GSI 16 (level, low) -> IRQ 16
bt878_probe: card id=[0x3000144f], Unknown card.

cat /proc/bus/input/devices:

I: Bus=0001 Vendor=144f Product=3000 Version=0001
N: Name="bttv IR (card=38)"
P: Phys=pci-0000:04:00.0/ir0
S: Sysfs=/class/input/input6
U: Uniq=
H: Handlers=kbd event6
B: EV=100003
B: KEY=10afc336 2150a48 0 0 0 404 80010000 190 4801 1e0000 4400 100000
10000ffc

--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux

From forum: Samba - linux

Re: Kerberos Ticket Forwarding patch/update

2008-07-24T19:07:44Z

Yes, from my experience with everything from XP to Vista Business, we've
never found a client who's had any ability to control how the flow of
kerberos authentication works while running through virtualized storage,
because this would be a nightmare for helpdesks.

If a client could disable the ability to use delegated proxy authentication
user error would result from the authentication error and helpdesk calls
would be the next step :)

Derrick

On 7/24/08 10:02 PM, "Andrew Bartlett" <abartlet@...> wrote:

> On Thu, 2008-07-24 at 23:27 +0100, Love Hörnquist Åstrand wrote:
>> Hello,
>>
>> That the computer it "trusted for delegation" doesn't mean that the
>> user want to delegate.
>>
>> The reason I'm asking is that when I asked msft about this, they said
>> they only delegated if GSS_C_DELGATE_FLAG and ok-as-delegate was set.
>> ok-as-delegate alone was not a critera alone for delegation. I want to
>> know if its true.
>>
>> If its true, and the user never sets GSS_C_DELEGATE_FLAG, samba
>> shouldn't delegate.
>
> The problem here is that if it's up to the user (ie, as a command line
> option), then none of this useful delegation stuff ever happens, and we
> end up giving hosts the right to make up arbitrary tickets, not just
> accept forwarded ones. I actually agree with Microsoft here, and the
> delegation should be controlled by the KDC.
>
> Andrew Bartlett

From forum: Samba - samba-technical

Re: Kerberos Ticket Forwarding patch/update

2008-07-24T19:02:23Z

On Thu, 2008-07-24 at 23:27 +0100, Love Hörnquist Åstrand wrote:

The problem here is that if it's up to the user (ie, as a command line
option), then none of this useful delegation stuff ever happens, and we
end up giving hosts the right to make up arbitrary tickets, not just
accept forwarded ones. I actually agree with Microsoft here, and the
delegation should be controlled by the KDC.

Andrew Bartlett

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

signature.asc (196 bytes) Download Attachment

From forum: Samba - samba-technical

Re: Samba 3.2 PDC - Creating Zone Identifier files and not able to read/write/delete them.

2008-07-24T18:10:19Z

On Tue, Jul 22, 2008 at 07:59:24PM +0200, Reinaldo Silva wrote:

> Hello,
>
> I use a Suse 11.0 as a Samba 3.2 PDC. The clients run XP SP3. I have
> upgraded a few weeks ago from Suse 10.3 and now all files tranfer that I do
> - for example, downloading a file using a web browser - it leaves a trash
> file named "transferd-file:Zone.Identifier" or "tranferd-file:encryptable".
>
> The odd thing is that from Windows I can`t read/write/delete these files.
> They appear with names like "hdje2423".
>
> Any help will be apreciated.

Looks like a bug in 3.2.0 that got missed in release.
We now handle named streams in xattrs or in a database
but if we're not using either of those modules we should
refuse to create them (as we did in Samba 3.0.x).

Try this patch, should fix it - will be in 3.2.1.
(attached to this post).

Either that or you can add:

vfs objects = streams_xattr

to the share definition and the named streams will
be correctly stored in xattr's instead (so long as
the filesystem supports them.

Jeremy.

diff --git a/source/smbd/open.c b/source/smbd/open.c
index 0d1dd31..2184e69 100644
--- a/source/smbd/open.c
+++ b/source/smbd/open.c
@@ -3052,6 +3052,11 @@ NTSTATUS create_file(connection_struct *conn,
ZERO_STRUCT(sbuf);
goto done;
}
+
+ if (!(conn->fs_capabilities & FILE_NAMED_STREAMS)) {
+ status = NT_STATUS_OBJECT_PATH_NOT_FOUND;
+ goto fail;
+ }
}

if ((req != NULL) && (req->flags2 & FLAGS2_DFS_PATHNAMES)) {

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

From forum: Samba - General

Re: IPv6 Australia?

2008-07-24T17:37:24Z

On Fri, 25 Jul 2008, Robert Edwards wrote:

> those devices have a very small CPU (and carbon foot-print) and I
> don't want to have to set up all sorts of firewall rules on them or
> on their behalf on my stateful firewall. They have absolutely no need
> to be visible from the rest of the Internet and rarely need to connect

This argument is bogus. You know the adage with firewalls - "that which
is not explicitly allowed is denied" (or dropped, should you be of that
persuasion ;).

If something should need to talk to those devices (or those devices should
need to talk to something on the outside) then your firewall should need
to be explicitly configured to do so, as you have done for your web server
under ipv4. Just because they *can* easily be addressed under ipv6
doesn't mean that they *should* be easily contacted.

I'm looking forward to ipv6, or something like it. I've only just set up
ekiga on my desktop here, and on my parent's machine down in Barham - it
lets them see (very small) moving pictures of their descendants... Thing
is - currently we need to use a "stun" server. I haven't found a free
STUN server in Australia yet, so we're going via the states - 300ms
latency. It's entirely possible I may be able to get around this with
suitable application of port-forwarding, packet rewriting, aadvark blood
and time. NOT having to do it, rather just allowing the desktops to be
addressed would be *far* preferable AFAICS. (aside: I could also go back
to playing with asterisk, I guess...)

> Bob Edwards.

Yours,
--
Peter Barker | Programmer,Sysadmin,Geek.
pbarker@... | You need a bigger hammer.
:: It's a hack! Expect underscores! - Nigel Williams
--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux

From forum: Samba - linux

DO NOT REPLY [Bug 5407] hlink.c:480: finish_hard_link: Assertion `flist != ((void *)0)' failed.

2008-07-24T16:41:40Z

https://bugzilla.samba.org/show_bug.cgi?id=5407

------- Comment #2 from wayned@... 2008-07-24 18:41 CST -------
Any more info? If you still get an error, try the latest dev version (3.1.0 in
git and nightly tar files) and specify --debug=hlink4 and let me know the
output for a failure run.

Also, specifying "--msgs2stderr" may help you to get errors back from the
"server" side (which is the receiver/generator in a local copy). FYI, you'd
use "-M --msgs2stderr" for a remote-shell copy (the option doesn't work with a
daemon copy).

--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

From forum: Samba - rsync

Re: laptop already gone, Server still available. Stuff, free to a god home.

2008-07-24T16:40:45Z

On Thu, Jul 24, 2008 at 18:04, Andrew Janke <a.janke@...> wrote:
> While we are flogging free stuff I have a D-Link DWL-900AP+ free to a
> good home if anyone wants it.

Gone. (x3)

a
--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux

From forum: Samba - linux

Re: IPv6 Australia?

2008-07-24T16:40:03Z

Sam Couter wrote:
> Robert Edwards <bob@...> wrote:
>> When the IPv4 address crunch comes, all that will happen is that a
>> market will open up for IPv4 address space. Those large corporations
>> etc. sitting on several class A's will make some money breaking them
>> up and flogging off the unused addresses as class C's.
>
> Excellent. Yet more money to be made by rich people by selling an
> artificially scarce resource.

That would be the rich people who invested lots of time and staff salary
dollars in developing the Internet in the first place...

When a disruptive technology comes along, the playing field changes.
Some people make some money, others may have to spend some. Get over it.

>
>> Unlike Sam (and many others), I think that NAT is cool and don't hate
>> it at all. All properly designed protocols work fine with NAT, so why
>> not?
>
> NAT relegates IP devices to the role of client only. They cannot act as
> a server. IP is supposed to be peer based. NAT breaks that.

IP back in the 60s when all hosts belonged to well managed organisations
and users accessed networks via multi-user time-sharing hosts (cf. a NAT
router/server with several/many "client-only" desktops/laptops/PDAs etc.
sitting behind it) was peer-to-peer.

>
> The biggest downside of the peer relationship being widely broken is
> that it becomes difficult to publish a service that a big player isn't
> willing to host. Imagine how far everyone's favourite and most abused
> protocol, HTTP, would have got if the big players at the time like AOL
> were in control and weren't interested in supporting a competitor to
> their already established distribution networks.

I have a single IPv4 address at home. I have a single web-server
sitting on/behind that address. I can (and do) "publish" several
websites on that address. Anything serious goes to a web-hosting
company (ala the "big players"?). I suspect that most people would
operate this way, even if they did have 2^64 IPv6 addresses at home.

I can also connect into my single IPv4 address at home over SSH (or
some other protocols) and manipulate all manner of devices that exist
in my house but are not visible on the rest of the Internet. Some of
those devices have a very small CPU (and carbon foot-print) and I
don't want to have to set up all sorts of firewall rules on them or
on their behalf on my stateful firewall. They have absolutely no need
to be visible from the rest of the Internet and rarely need to connect
out. If my future fridge manufacturer wants to ping my fridge to check
how cold it is (or maybe spy on what products I keep in it), then I
would prefer them to come in via an authenticated service on my IPv4
address/NAT router/server, not directly to my (future) fridge.

>
>> So no compelling advantage for IPv6 other than more address space (to
>> defend against in your firewall scripts/blacklists etc.) and bigger
>> addresses (takes more CPU to hash when connection tracking and more
>> memory to store etc.). DNS for IPv6 is a real doozy (esp. reverse DNS!).
>
> On the other hand, the strict hierarchical routing scheme means routers
> don't need to store such massive routing tables.
>

We'll wait and see how "strictly" adhered to the hierarchical routing
scheme really ends up. I am not so sure. The so-called "massive routing
tables" of IPv4 aren't all that massive these days, with CIDR and other
policies having reduced the potential number of entries. In any case,
it is not an issue for most people and those who do care have solved
it or are using IPv6 as their backbone routing infrastructure.

IPv4 will eventually go away. Whether it is replaced with IPv6 or some
other much more exciting protocol, we'll wait and see. I suspect that
a new "killer-app" protocol will come along before IPv6 is widely
adopted and we'll end up jumping over it (cf. FDDI back in the 90s).

Cheers,

Bob Edwards.

--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux

From forum: Samba - linux

RE: correction to SMB SMB_QUERY_FILE_ALL_INFO info level

2008-07-24T16:32:25Z

Hi James,

We've concluded our investigation and upcoming versions of the document will reflect changes similar to the following:

2.2.13.2 TRANS2_QUERY_FILE_INFORMATION Response
A server MUST send a TRANS2_QUERY_FILE_INFORMATION response in reply to an SMB_COM_TRANSACTION2 client request with a TRANS2_QUERY_FILE_INFORMATION subcommand when the request is successful.
The Data block of the transaction response contains the requested information as follows. Note that this Data block definition augments the definition specified in [CIFS] section 4.2.15. Where differences exist, the information supplied here supercedes information in [CIFS].
This structure is returned by the server whether the query specifies SMB_QUERY_FILE_ALL_INFO level or the native NT passthrough level "FileAllInformation".

0 1 2 3 4 5 6 7 8 9 1
0 1 2 3 4 5 6 7 8 9 2
0 1 2 3 4 5 6 7 8 9 3
0 1
CreationTime
...
LastAccessTime
...
LastWriteTime
...
ChangeTime
...
Attributes
AllocationSize
...
EndofFile
...
NumberOfLinks
DeletePending Directory
Pad EASize
... FileNameLength
... FileName (variable)
...
CreationTime (8 bytes): Time of the file creation.
LastAccessTime (8 bytes): Time of the most recent file access.
LastWriteTime (8 bytes): Time of the most recent write in the file.
ChangeTime (8 bytes): Time of the most recent change to the file.
Attributes (4 bytes): File attributes.
AllocationSize (8 bytes): Allocated size, in bytes, of the file.
EndofFile (8 bytes): Offset to the first free byte in the file.
NumberOfLinks (4 bytes): Number of hard links to the file.
DeletePending (2 bytes): Indicates whether the file is marked for deletion.
Directory (2 bytes): Indicates whether the file is a directory.
Pad (2 bytes): Unused. Provided for alignment.
EASize (4 bytes): Size, in bytes, of the file's extended attributes.
FileNameLength (4 bytes): Length, in bytes, of the file name.
FileName (variable): Name of the file.
This structure is also returned by the TRANS2_QUERY_PATH_INFORMATION Response as specified in section 2.2.13.4.
The FILE_ALL_INFORMATION structure described in [MS-FSCC], is NOT used by [MS-SMB].
Thanks for your help!

I'm attaching a .pdf doc so you can see the answer with the correct format.

Regards,

Sebastian Canevari
Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
7100 N Hwy 161, Irving, TX - 75039
"Las Colinas - LC2"
Tel: +1 469 775 7849
e-mail: sebastc@...

We're hiring

-----Original Message-----
From: cifs-protocol-bounces+sebastc=microsoft.com@... [mailto:cifs-protocol-bounces+sebastc=microsoft.com@...] On Behalf Of James Peach
Sent: Thursday, June 19, 2008 10:55 AM
To: cifs-protocol@...
Subject: [cifs-protocol] correction to SMB SMB_QUERY_FILE_ALL_INFO info level

Hi all,

Just posting this note so that there is something searchable on the web.

The SMB_QUERY_FILE_ALL_INFO info level has been specified incorrectly
as far back as the Leach-Naik drafts. The correct format for this
response is:

Data Block Encoding Description
===================================================================
LARGE_INTEGER CreationTime Time when file was created
LARGE_INTEGER LastAccessTime Time of last file access
LARGE_INTEGER LastWriteTime Time of last write to the file
LARGE_INTEGER ChangeTime Time when file was last changed
ULONG Attributes File Attributes
LARGE_INTEGER AllocationSize Allocated size of the file in number of
bytes
LARGE_INTEGER EndofFile Offset to the first free byte in the file
ULONG NumberOfLinks Number of hard links to the file
BOOLEAN DeletePending Indicates whether the file is marked for deletion
BOOLEAN Directory Indicates whether the file is a directory
USHORT Unknown Could be a padd value?
ULONG EASize Size of the file's extended attributes in bytes
ULONG FileNameLength Length of the file name in number of bytes
STRING FileName Name of the file

All versions of Windows and Samba get this right. AFAIK the only
modern SMB client that uses this info level is the Mac OSX client. I
believe that some versions of NetApp filers get this wrong. Wireshark
used to get this wrong, but recent versions get it right.

I posted this on the MSDN File Services forum, but it ate my
formatting. Hopefully this is more legible :)

James
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

JAmes.pdf (261K) Download Attachment

From forum: Samba - cifs-protocol

Re: Kerberos Ticket Forwarding patch/update

2008-07-24T16:27:21Z

> Maybe the client don't want to authenticate to that service, you are forcing
> it upon them to always delegate, even for services which they don't need to
> delegate too.
>
I¹m not sure I follow... If a user goes to //proxy.example.com/share01 they
would have to authenticate with a forwardable ticket, otherwise they¹ll be
declined access to the back-end storage and not be able to make a successful
kerberos connection. True, if, for some reason, a random server joined to a
windows domain had ³Trust for delegation² set, the client would send two
tickets when only one was needed, but that would be an odd configuration.
You¹re saying the client would have to be forced to say ³I¹d like to be able
to received tickets if this host is trusted for delegation²? If so, that¹s
not the standard MS Windows behavior, as there is no place to turn on/off a
client side trust relationship that I¹ve seen.
>
> To test the behaivor you need to use SSPI directly and test the behavior of
> the windows SSPI Kerberos interface.
>
You mean connect to the proxy via Windows kerberos?

Derrick

>
>
>
> 24 jul 2008 kl. 23.55 skrev Derrick Schommer:
>
>>
>>
>> I¹m not sure how Microsoft handles it internally, what I do know is if the
>> client doesn¹t want¹ to delegate, than they¹re going to be declined the
>> ability to authenticate because the server is virtualizing the back-end
>> storage. You cannot authenticate directly with the virtualized system without
>> using a management address. The client wouldn¹t gain any advantage from not
>> allowing the delegated trust.
>>
>> What I do know is Microsoft automatically sends the second ticket to the
>> Acopia ARX when the device has been trusted for delegation, there has never
>> been a case where this isn¹t true. The minute you disable trust for
>> delegation you¹ll see the security blog is half as large (since it¹s missing
>> a ticket). Given the data is encrypted it¹s not really easy to know what¹s
>> going on under the hood.
>>
>>
>> Derrick
>>
>> On 7/24/08 6:27 PM, "Love Hörnquist Åstrand" <lha@...> wrote:
>>
>>
>>> Hello,
>>>
>>> That the computer it "trusted for delegation" doesn't mean that the
>>> user want to delegate.
>>>
>>> The reason I'm asking is that when I asked msft about this, they said
>>> they only delegated if GSS_C_DELGATE_FLAG and ok-as-delegate was set.
>>> ok-as-delegate alone was not a critera alone for delegation. I want to
>>> know if its true.
>>>
>>> If its true, and the user never sets GSS_C_DELEGATE_FLAG, samba
>>> shouldn't delegate.
>>>
>>> Love
>>>
>>>
>>>
>>> 24 jul 2008 kl. 23.03 skrev Derrick Schommer:
>>>
>>>> > The OK_AS_DELEGATE is set when the ticket is granted based on a
>>>> > computer account being told, on the domain controller, "trusted for
>>>> > delegation"
>>>> >
>>>> > In those cases, we want to forward on the second ticket for that
>>>> > system so that it can negotiate with the back-end storage that it's
>>>> > virtualizing.
>>>> >
>>>> > Derrick
>>>> >
>>>> > -----Original Message-----
>>>> > From: Love Hörnquist Åstrand [mailto:lha@...]
>>>> > Sent: Thursday, July 24, 2008 17:53
>>>> > To: Derrick Schommer
>>>> > Cc: samba-technical@...
>>>> > Subject: Re: Kerberos Ticket Forwarding patch/update
>>>> >
>>>> > Hello allo,
>>>> >
>>>> > I would really like to know the behavior of windows, is the the
>>>> > OK_AS_DELEGATE flag that really is used to determine if ticket should
>>>> > be delegated.
>>>> >
>>>> > Or is is that application that thinks it should by setting
>>>> > GSS_C_DELEGATE and the SSPI library that strips is if the
>>>> > OK_AS_DELEGATE isn't set by the KDC on the service ticket.
>>>> >
>>>> > If the user never meant to delegate, samba shouldn't default to.
>>>> >
>>>> > Love
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > 24 jul 2008 kl. 21.28 skrev Derrick Schommer:
>>>> >
>>>>> >> Hi,
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> I'm looking to commit a patch for the 3.0 code base and the 3.2 code
>>>>> >> base to allow samba using Kerberos authentication to work with proxy
>>>>> >> devices which are set to be "trusted for delegation" in a Windows
>>>>> >> domain. The update, in clikrb5.c would add detection for tickets with
>>>>> >> OK_AS_DELEGATE and would then request a forwardable ticket from the
>>>>> >> KDC
>>>>> >> and send it along with the krb5_mk_req_extended() function call.
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> This would allow operating systems with Samba 3.x to interoperate
>>>>> >> with
>>>>> >> the F5 Acopia ARX product line for storage virtualization along with
>>>>> >> any
>>>>> >> other future virtualization vendors. I'm not sure if I send patches
>>>>> >> to
>>>>> >> this mailer or not (as this patch is 260 lines long and I have one
>>>>> >> for
>>>>> >> 3.0.x and 3.2.x). I'd love for the team to review it and do what
>>>>> >> would
>>>>> >> be needed to commit it into the projects.
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> Thanks in advance.
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> Derrick Schommer | Corporate Systems Engineer
>>>>> >>
>>>>> >> F5 Networks
>>>>> >>
>>>>> >> P 978.513.2900
>>>>> >>
>>>>> >> F 978.513.2990
>>>>> >>
>>>>> >> www.f5.com <http://www.f5.com> <http://www.f5.com>
>>>>> >>
>>>>> >> D 978.513.2960
>>>>> >>
>>>>> >> M 603.765.0012
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> <image001.gif>
>>>> >
>>>
>>>
>>>
>>
>>
>
>

From forum: Samba - samba-technical

DO NOT REPLY [Bug 5633] New: --pidfile option for rsync daemon

2008-07-24T16:14:46Z

https://bugzilla.samba.org/show_bug.cgi?id=5633

Summary: --pidfile option for rsync daemon
Product: rsync
Version: 3.0.3
Platform: Other
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P3
Component: core
AssignedTo: wayned@...
ReportedBy: arekm@...
QAContact: rsync-qa@...

This is feature request.

Please add ability to specify different pid file at cmdline time so it will be
able to run multiple daemons with different options specified only at cmdline
time and the same config file (so no need to duplicate config file just to
change some options.

Something like --pidfile /tmp/other.pid

--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

From forum: Samba - rsync

Re: [SCM] Samba Shared Repository - branch v3-3-test updated - release-3-2-0pre2-3410-g1500401

2008-07-24T16:10:45Z

On Thu, Jul 24, 2008 at 11:44:54PM +0200, Volker Lendecke wrote:
> Just curious -- shouldn't this be provided for free by
> function prototypes?

Yes, that's true. I've been caught so many times though
by people passing &uid_t's to functions with uint_t *
prototypes that I get explicitly paranoid these days :-).

Jeremy.

From forum: Samba - samba-technical

Re: Kerberos Ticket Forwarding patch/update

2008-07-24T16:03:46Z

Hello Derrick,

Maybe the client don't want to authenticate to that service, you are
forcing it upon them to always delegate, even for services which they
don't need to delegate too.

To test the behaivor you need to use SSPI directly and test the
behavior of the windows SSPI Kerberos interface.

Love

24 jul 2008 kl. 23.55 skrev Derrick Schommer:

>
> I’m not sure how Microsoft handles it internally, what I do know is
> if the client doesn’t ‘want’ to delegate, than they’re going to be
> declined the ability to authenticate because the server is
> virtualizing the back-end storage. You cannot authenticate directly
> with the virtualized system without using a management address. The
> client wouldn’t gain any advantage from not allowing the delegated
> trust.
>
> What I do know is Microsoft automatically sends the second ticket to
> the Acopia ARX when the device has been trusted for delegation,
> there has never been a case where this isn’t true. The minute you
> disable trust for delegation you’ll see the security blog is half as
> large (since it’s missing a ticket). Given the data is encrypted
> it’s not really easy to know what’s going on under the hood.
>
>
> Derrick
>
> On 7/24/08 6:27 PM, "Love Hörnquist Åstrand" <lha@...> wrote:
>
>> Hello,
>>
>> That the computer it "trusted for delegation" doesn't mean that the
>> user want to delegate.
>>
>> The reason I'm asking is that when I asked msft about this, they said
>> they only delegated if GSS_C_DELGATE_FLAG and ok-as-delegate was set.
>> ok-as-delegate alone was not a critera alone for delegation. I want
>> to
>> know if its true.
>>
>> If its true, and the user never sets GSS_C_DELEGATE_FLAG, samba
>> shouldn't delegate.
>>
>> Love
>>
>>
>>
>> 24 jul 2008 kl. 23.03 skrev Derrick Schommer:
>>
>> > The OK_AS_DELEGATE is set when the ticket is granted based on a
>> > computer account being told, on the domain controller, "trusted for
>> > delegation"
>> >
>> > In those cases, we want to forward on the second ticket for that
>> > system so that it can negotiate with the back-end storage that it's
>> > virtualizing.
>> >
>> > Derrick
>> >
>> > -----Original Message-----
>> > From: Love Hörnquist Åstrand [mailto:lha@...]
>> > Sent: Thursday, July 24, 2008 17:53
>> > To: Derrick Schommer
>> > Cc: samba-technical@...
>> > Subject: Re: Kerberos Ticket Forwarding patch/update
>> >
>> > Hello allo,
>> >
>> > I would really like to know the behavior of windows, is the the
>> > OK_AS_DELEGATE flag that really is used to determine if ticket
>> should
>> > be delegated.
>> >
>> > Or is is that application that thinks it should by setting
>> > GSS_C_DELEGATE and the SSPI library that strips is if the
>> > OK_AS_DELEGATE isn't set by the KDC on the service ticket.
>> >
>> > If the user never meant to delegate, samba shouldn't default to.
>> >
>> > Love
>> >
>> >
>> >
>> >
>> > 24 jul 2008 kl. 21.28 skrev Derrick Schommer:
>> >
>> >> Hi,
>> >>
>> >>
>> >>
>> >> I'm looking to commit a patch for the 3.0 code base and the 3.2
>> code
>> >> base to allow samba using Kerberos authentication to work with
>> proxy
>> >> devices which are set to be "trusted for delegation" in a Windows
>> >> domain. The update, in clikrb5.c would add detection for tickets
>> with
>> >> OK_AS_DELEGATE and would then request a forwardable ticket from
>> the
>> >> KDC
>> >> and send it along with the krb5_mk_req_extended() function call.
>> >>
>> >>
>> >>
>> >> This would allow operating systems with Samba 3.x to interoperate
>> >> with
>> >> the F5 Acopia ARX product line for storage virtualization along
>> with
>> >> any
>> >> other future virtualization vendors. I'm not sure if I send
>> patches
>> >> to
>> >> this mailer or not (as this patch is 260 lines long and I have one
>> >> for
>> >> 3.0.x and 3.2.x). I'd love for the team to review it and do what
>> >> would
>> >> be needed to commit it into the projects.
>> >>
>> >>
>> >>
>> >> Thanks in advance.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Derrick Schommer | Corporate Systems Engineer
>> >>
>> >> F5 Networks
>> >>
>> >> P 978.513.2900
>> >>
>> >> F 978.513.2990
>> >>
>> >> www.f5.com <http://www.f5.com>
>> >>
>> >> D 978.513.2960
>> >>
>> >> M 603.765.0012
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> <image001.gif>
>> >
>>
>>

From forum: Samba - samba-technical

Re: Kerberos Ticket Forwarding patch/update

2008-07-24T15:55:00Z

I¹m not sure how Microsoft handles it internally, what I do know is if the
client doesn¹t want¹ to delegate, than they¹re going to be declined the
ability to authenticate because the server is virtualizing the back-end
storage. You cannot authenticate directly with the virtualized system
without using a management address. The client wouldn¹t gain any advantage
from not allowing the delegated trust.

What I do know is Microsoft automatically sends the second ticket to the
Acopia ARX when the device has been trusted for delegation, there has never
been a case where this isn¹t true. The minute you disable trust for
delegation you¹ll see the security blog is half as large (since it¹s missing
a ticket). Given the data is encrypted it¹s not really easy to know what¹s
going on under the hood.

Derrick

On 7/24/08 6:27 PM, "Love Hörnquist Åstrand" <lha@...> wrote:

> Hello,
>
> That the computer it "trusted for delegation" doesn't mean that the
> user want to delegate.
>
> The reason I'm asking is that when I asked msft about this, they said
> they only delegated if GSS_C_DELGATE_FLAG and ok-as-delegate was set.
> ok-as-delegate alone was not a critera alone for delegation. I want to
> know if its true.
>
> If its true, and the user never sets GSS_C_DELEGATE_FLAG, samba
> shouldn't delegate.
>
> Love
>
>
>
> 24 jul 2008 kl. 23.03 skrev Derrick Schommer:
>
>> > The OK_AS_DELEGATE is set when the ticket is granted based on a
>> > computer account being told, on the domain controller, "trusted for
>> > delegation"
>> >
>> > In those cases, we want to forward on the second ticket for that
>> > system so that it can negotiate with the back-end storage that it's
>> > virtualizing.
>> >
>> > Derrick
>> >
>> > -----Original Message-----
>> > From: Love Hörnquist Åstrand [mailto:lha@...]
>> > Sent: Thursday, July 24, 2008 17:53
>> > To: Derrick Schommer
>> > Cc: samba-technical@...
>> > Subject: Re: Kerberos Ticket Forwarding patch/update
>> >
>> > Hello allo,
>> >
>> > I would really like to know the behavior of windows, is the the
>> > OK_AS_DELEGATE flag that really is used to determine if ticket should
>> > be delegated.
>> >
>> > Or is is that application that thinks it should by setting
>> > GSS_C_DELEGATE and the SSPI library that strips is if the
>> > OK_AS_DELEGATE isn't set by the KDC on the service ticket.
>> >
>> > If the user never meant to delegate, samba shouldn't default to.
>> >
>> > Love
>> >
>> >
>> >
>> >
>> > 24 jul 2008 kl. 21.28 skrev Derrick Schommer:
>> >
>>> >> Hi,
>>> >>
>>> >>
>>> >>
>>> >> I'm looking to commit a patch for the 3.0 code base and the 3.2 code
>>> >> base to allow samba using Kerberos authentication to work with proxy
>>> >> devices which are set to be "trusted for delegation" in a Windows
>>> >> domain. The update, in clikrb5.c would add detection for tickets with
>>> >> OK_AS_DELEGATE and would then request a forwardable ticket from the
>>> >> KDC
>>> >> and send it along with the krb5_mk_req_extended() function call.
>>> >>
>>> >>
>>> >>
>>> >> This would allow operating systems with Samba 3.x to interoperate
>>> >> with
>>> >> the F5 Acopia ARX product line for storage virtualization along with
>>> >> any
>>> >> other future virtualization vendors. I'm not sure if I send patches
>>> >> to
>>> >> this mailer or not (as this patch is 260 lines long and I have one
>>> >> for
>>> >> 3.0.x and 3.2.x). I'd love for the team to review it and do what
>>> >> would
>>> >> be needed to commit it into the projects.
>>> >>
>>> >>
>>> >>
>>> >> Thanks in advance.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> Derrick Schommer | Corporate Systems Engineer
>>> >>
>>> >> F5 Networks
>>> >>
>>> >> P 978.513.2900
>>> >>
>>> >> F 978.513.2990
>>> >>
>>> >> www.f5.com <http://www.f5.com>
>>> >>
>>> >> D 978.513.2960
>>> >>
>>> >> M 603.765.0012
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> <image001.gif>
>> >
>
>

From forum: Samba - samba-technical

Re: Kerberos Ticket Forwarding patch/update

2008-07-24T15:27:19Z

Hello,

That the computer it "trusted for delegation" doesn't mean that the
user want to delegate.

The reason I'm asking is that when I asked msft about this, they said
they only delegated if GSS_C_DELGATE_FLAG and ok-as-delegate was set.
ok-as-delegate alone was not a critera alone for delegation. I want to
know if its true.

If its true, and the user never sets GSS_C_DELEGATE_FLAG, samba
shouldn't delegate.

Love

24 jul 2008 kl. 23.03 skrev Derrick Schommer:

> The OK_AS_DELEGATE is set when the ticket is granted based on a
> computer account being told, on the domain controller, "trusted for
> delegation"
>
> In those cases, we want to forward on the second ticket for that
> system so that it can negotiate with the back-end storage that it's
> virtualizing.
>
> Derrick
>
> -----Original Message-----
> From: Love Hörnquist Åstrand [mailto:lha@...]
> Sent: Thursday, July 24, 2008 17:53
> To: Derrick Schommer
> Cc: samba-technical@...
> Subject: Re: Kerberos Ticket Forwarding patch/update
>
> Hello allo,
>
> I would really like to know the behavior of windows, is the the
> OK_AS_DELEGATE flag that really is used to determine if ticket should
> be delegated.
>
> Or is is that application that thinks it should by setting
> GSS_C_DELEGATE and the SSPI library that strips is if the
> OK_AS_DELEGATE isn't set by the KDC on the service ticket.
>
> If the user never meant to delegate, samba shouldn't default to.
>
> Love
>
>
>
>
> 24 jul 2008 kl. 21.28 skrev Derrick Schommer:
>
>> Hi,
>>
>>
>>
>> I'm looking to commit a patch for the 3.0 code base and the 3.2 code
>> base to allow samba using Kerberos authentication to work with proxy
>> devices which are set to be "trusted for delegation" in a Windows
>> domain. The update, in clikrb5.c would add detection for tickets with
>> OK_AS_DELEGATE and would then request a forwardable ticket from the
>> KDC
>> and send it along with the krb5_mk_req_extended() function call.
>>
>>
>>
>> This would allow operating systems with Samba 3.x to interoperate
>> with
>> the F5 Acopia ARX product line for storage virtualization along with
>> any
>> other future virtualization vendors. I'm not sure if I send patches
>> to
>> this mailer or not (as this patch is 260 lines long and I have one
>> for
>> 3.0.x and 3.2.x). I'd love for the team to review it and do what
>> would
>> be needed to commit it into the projects.
>>
>>
>>
>> Thanks in advance.
>>
>>
>>
>>
>>
>> Derrick Schommer | Corporate Systems Engineer
>>
>> F5 Networks
>>
>> P 978.513.2900
>>
>> F 978.513.2990
>>
>> www.f5.com <http://www.f5.com>
>>
>> D 978.513.2960
>>
>> M 603.765.0012
>>
>>
>>
>>
>>
>> <image001.gif>
>

From forum: Samba - samba-technical

RE: Reserved krb5 error (29)

2008-07-24T15:23:08Z

Check your Windows event logs to see if there are any Kerberos errors
there.

Dave Daugherty
Centrify

> On Behalf Of Herb Lewis
> Sent: Thursday, July 24, 2008 3:02 PM

> I'm having trouble authenticating to a W2k SP4 domain. the join said
it
> worked and wbinfo -t returns success but wbinfo -n returns errors and
I
> see the following in my winbindd logs

> Kinit failed: Reserved krb5 error (29)

> what is this error? This is samba 3.2 and 3.0.26a both

From forum: Samba - samba-technical

Re: Reserved krb5 error (29)

2008-07-24T15:22:14Z

24 jul 2008 kl. 23.01 skrev Herb Lewis:

> I'm having trouble authenticating to a W2k SP4 domain. the join said
> it
> worked and wbinfo -t returns success but wbinfo -n returns errors
> and I
> see the following in my winbindd logs
>
> Kinit failed: Reserved krb5 error (29)

Probably KDC_ERR_SVC_UNAVAILABLE translated into
KRB5KDC_ERR_SVC_UNAVAILABLE, your kdc didn't want to answer your right
now, please try again later (or try another KDC).

Released Heimdal supports this, and MIT might do with 1.6, for sure
with yet to be released 1.7.

Love

From forum: Samba - samba-technical

RE: Kerberos Ticket Forwarding patch/update

2008-07-24T15:03:11Z

The OK_AS_DELEGATE is set when the ticket is granted based on a computer account being told, on the domain controller, "trusted for delegation"

In those cases, we want to forward on the second ticket for that system so that it can negotiate with the back-end storage that it's virtualizing.

Derrick

-----Original Message-----
From: Love Hörnquist Åstrand [mailto:lha@...]
Sent: Thursday, July 24, 2008 17:53
To: Derrick Schommer
Cc: samba-technical@...
Subject: Re: Kerberos Ticket Forwarding patch/update

Hello allo,

I would really like to know the behavior of windows, is the the
OK_AS_DELEGATE flag that really is used to determine if ticket should
be delegated.

Or is is that application that thinks it should by setting
GSS_C_DELEGATE and the SSPI library that strips is if the
OK_AS_DELEGATE isn't set by the KDC on the service ticket.

If the user never meant to delegate, samba shouldn't default to.

Love

24 jul 2008 kl. 21.28 skrev Derrick Schommer:

> Hi,
>
>
>
> I'm looking to commit a patch for the 3.0 code base and the 3.2 code
> base to allow samba using Kerberos authentication to work with proxy
> devices which are set to be "trusted for delegation" in a Windows
> domain. The update, in clikrb5.c would add detection for tickets with
> OK_AS_DELEGATE and would then request a forwardable ticket from the
> KDC
> and send it along with the krb5_mk_req_extended() function call.
>
>
>
> This would allow operating systems with Samba 3.x to interoperate with
> the F5 Acopia ARX product line for storage virtualization along with
> any
> other future virtualization vendors. I'm not sure if I send patches to
> this mailer or not (as this patch is 260 lines long and I have one for
> 3.0.x and 3.2.x). I'd love for the team to review it and do what would
> be needed to commit it into the projects.
>
>
>
> Thanks in advance.
>
>
>
>
>
> Derrick Schommer | Corporate Systems Engineer
>
> F5 Networks
>
> P 978.513.2900
>
> F 978.513.2990
>
> www.f5.com <http://www.f5.com>
>
> D 978.513.2960
>
> M 603.765.0012
>
>
>
>
>
> <image001.gif>

From forum: Samba - samba-technical