When is "Sealing" required (SDS.Protocols)

[Magnusb]

For some operation it looks like you need to use SessionOptions.Sealing=
true (Enable Kerberos encryption). Looks like you need to set it when
you set password. But for which other operations/circumstances do you
need to enable Kerberos encryption?

Also is there any difference of using Selealing and Signing?
Documentation says that both enable Kerberos encryption

[Joe Kaplan]

Documentation sucks here.

LDAP password change requires 128 bit encryption by default which the
Sealing flag has supported since Win2K3. Generally, it does not hurt to
leave it on all the time. It just encrypts your traffic to the DC.

It also does not require Kerb auth and will work with NTLM on all recent MS
OSs.

Signing just signs the traffic to prevent tampering. It is generally used
in conjunction with Sealing. Note that it is generally turned on by default
at the OS level for you but I'd suggest using it.

Unless you have a need for plaintext LDAP traffic, I'd suggest leaving
signing/sealing on all the time. If you do need plaintext traffic, I'd use
that as an exception. Note that the authentication itself is not plaintext
since you are using NTLM or Kerb. It is just the actual LDAP
request/response data that is plaintext unless you use sealing.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
"Magnusb" <mag...@sbbs.se> wrote in message
news:MPG.25510aad2...@msnews.microsoft.com...

[Magnusb]

In article <O1uSIr1V...@TK2MSFTNGP04.phx.gbl>,
joseph....@removethis.accenture.com says...
> Documentation sucks here.

Again :-). SDSP documentation is really bad in general.

> Unless you have a need for plaintext LDAP traffic, I'd suggest leaving
> signing/sealing on all the time. If you do need plaintext traffic, I'd use
> that as an exception. Note that the authentication itself is not plaintext
> since you are using NTLM or Kerb. It is just the actual LDAP
> request/response data that is plaintext unless you use sealing.

We sometime also access non-ms LDAP servers like Sun directory. if
signing/sealing is on will it automatically be turned off if the
recieving server does not support it?

Thank you

[Joe Kaplan]

You'll probably end up needing/wanting some directory-specific code paths to
support some of these things. For example, you would likely not be using
Negotiate auth with Sun directory in general since that's a Windows thing,
so you would probably use simple bind and SSL or something like that?
Basically, I think you'll need to carefully set the appropriate session
options based on the type of directory. However, once you have things sorted
by directory, I don't see you having a problem with leaving signing and
sealing on with a connection to AD.

You could also take the approach of trying to go to lowest common
denominator and using simple bind/SSL with AD as well as other directories.
AD LDAP password change also works with SSL. The problem here is that lots
of AD deployments don't have SSL.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
"Magnusb" <mag...@sbbs.se> wrote in message

news:MPG.255237a5e...@msnews.microsoft.com...

[Magnusb]

In article <udnCsb9...@TK2MSFTNGP06.phx.gbl>,
joseph....@removethis.accenture.com says...

> You'll probably end up needing/wanting some directory-specific code paths to
> support some of these things. For example, you would likely not be using
> Negotiate auth with Sun directory in general since that's a Windows thing,
> so you would probably use simple bind and SSL or something like that?
>

Yes true. We already have some conditional settings depending of which
type of directory it is.

Is there any disadvantages (liek worse performance) of always having
sealing turned on (when it is supported)?

[Joe Kaplan]

You can't sniff the wire traffic for troubleshooting purposes. I'm unware of
a feature that REQUIRES unencrypted traffic though,.

I'm sure there is a perf hit associated with this but I would be surprised
if it was substantial. As with all perf concerns, always test/measure and
never assume. My understanding is that these features are quite fast.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
"Magnusb" <mag...@sbbs.se> wrote in message

news:MPG.25528cce...@msnews.microsoft.com...