Directory Programming .NET

For the sake of performance, I am using S.DS.P to bulk load an Adam with about 1M users. The Adam is configured to require SSL for password updates. So, is it possible to establish a non-SSL connection to upload all the users and their attributes, exluding passwords, and then switching to SSL to modify the password attribute all using the same LDAP connection? Or do I need to open two connections at the same time to do this, one SSL and the other non-SSL?

Thanks for any suggestions.

-Dave

I don't understand why you would want to do this as it should be much faster to add the user with the password all in one go than to do it in two passes.  What does your code for adding a user look like?

In theory this is possible using StartTransportLayerSecurity, but it doesn't seem like you should have to do this.

The other thing is that ADAM and AD DO NOT require SSL for password operations, they require encryption at 128 bit strength.  This can be achieved with either SSL or any other SSPI auth mechanism.

Joe,

Our Adam instance is configured for two ports. One SSL and the other non-SSL. I wanted to use the non-SSL port for all updates to the Adam with the exception of password updates. I tried setting the password on the non-SSL port connection, but it fails. It works if using the SSL port.

I guess I'm not clear how to use encryption if not using SSL. The Adam I'm talking to is in our DMZ, so I don't have NTLM in place as there is no Active Directory setup in our DMZ.

How would I implement encryption if not using SSL in order to send over passwords?

Thanks for any suggestions.

-Dave

It depends on the auth method you are using.  NTLM will work fine to a standalone machine with a local machine account.  You don't need AD for NTLM. 

However, NTLM auth requires binding as a Windows user to ADAM.  If you are binding as an ADAM user, you must use simple bind (AuthTypes.Basic) or Digest auth.

Even still, you should be able to get SSPI channel encryption with Digest auth, so that should also work when binding with an ADAM user.  To get SSPI channel encryption, use Negotiate or Digest auth, don't use SSL and set the Sealing session option.

The key thing that I've been trying to get across is that the encryption requirement for password operations can be achieved with either SSL or the Sealing flag (SSPI encryption).  In many cases you'll hear that SSL must be used, but that isn't totally true.  Additionally, no certificate is required to get SSPI.  It is natively supported by NTLM, Kerberos and Digest.

You should also be able to switch back and forth between SSL and non-SSL if you want.

Joe,

I still cannot get digest auth to work. Here's what I'm doing:

LdapConnection connection;

connection = new LdapConnection(hostNameAndPort); // using the NON-SSL port

connection.AutoBind = true;

LdapSessionOptions options = connection.SessionOptions;

options.Sealing = true;

options.ProtocolVersion = 3;

options.SecureSocketLayer = false;

connection.AuthType = AuthType.Digest;

NetworkCredential credential = new NetworkCredential(userName, password);

connection.Credential = credential;

// Attempt to bind to the Adam server

connection.Bind();

When the call to Bind() is done, it throws an exception. The message says: The supplied credential is invalid. However, if I use the SSL port, set the AuthType = AuthType.Basic and set the  SecureSocketLayer property to true, then the bind succeeds using the same id/password as before.

Is there something else I need to do here that I'm not doing?

Thanks for any suggestions.

-Dave

 

I assume that you are definitely trying to bind as an ADAM user, right?

Digest auth can be very sensitive about the user name format and is actually somewhat case sensitive as well.

Make sure you are using either the displayName or UPN for the username and use the same case you used when you entered it.  Using all lower case when setting it is usually the best bet.

Joe,

Actually, I'm wondering if my attempt at using the non-SSL port is going to be worth the hassle. Even if I do manage to get the Digest auth methd to work along with the Sealing option, won't that encrypt all the traffic anyway, just like SSL would do? The only reason I'm trying to get the non-SSL connection to work is so I can send over passwords, which need to be encrypted. But if all the traffic will be encrypted anyway, then there's not much point is there? The performance won't be any better.

Also, switching between SSL and non-SSL (which I can't figure out how to do either) looks like it requires me to perform a new bind() operation on each switch which would be an additional overhead if loading 1M users.

So, if using AuthType.Digest and the Sealing option will encrypt all traffic anyway, I may as well just use SSL, won't the performance be the same?

-Dave

Well, I am using the DN of the Adam user, which looks like this:

CN=AdamAdmin,OU=Users,DC=ESPP

The displayName on this account is: ADAMAdmin

I'll trying using the displayName and see how that works.

-Dave

I tried using the displayName of the ADAM account to use for authentication and I still get invalid credentials when trying to bind using Digest auth with the sealing option.

Maybe this has something to do with how the Adam is configured.

I assume I don't have to use the SSL port when using Digest auth with Sealing? I was trying all of this over the non-SSL port.

So, I can bind over the non-SSL port using AuthType.Basic and SecureSocketLayer=false, and I bind over the SSL port using AuthType.Basic and SecureSocketLayer=true. But I cannot bind over the non-SSL port using AuthType.Digest, with SecureSocketLayer=false and options.Sealing=true. The last results in invalid credentials.

I think I'm going to have to live with the SSL connection. And if the AuthType.Digest with sealing is going to encrypt all the traffic anyway, then it sounds like the performance will be about the same with either.

-Dave

I don't know why Digest auth is failing here.  Eliminating the Sealing flag wouldn't be a bad idea but that should not matter as the encryption does not start until after the authentication succeeds (that is how the key is bootstrapped) and you aren't getting that far.

The only thing I can think of here is a case sensitivity issue with the display name, but using all upper or lower case should work in either event.  Checking the security event log on the ADAM server may provide more detail as to why it won't work.  I'm basically out of ideas though.  :)

That said, since you do have functional SSL, you should be able to live without Digest auth and still have secure binds and password operations.  The key thing to determine is whether it is faster to create the users with a non-SSL connection and then go back in a second batch and set passwords or to do the complete user provisioning in a single LDAP Add operation.

My guess is that the single operation approach will be fastest, but as with all perf stuff, you always measure and never assume.

You might also be able to get a nice boost by using multiple threads or processes to batch up the add operations or to use LDAP asynch operations on the client side for the actual Add operations.  All that adds complexity though.

One thing I have seen people do is to simply batch out the add operations into a bunch of LDIF files and do the provisioning from the command line by running LDIFDE multiple times.  There isn't a huge reason why this type of thing needs to be done in code.

Best of luck!

Joe,

Thanks for your time and help here. I think I'm going to just live with the SSL connection and do everything over that connection. I think it will be fast enough actually. As for the case I was using in the credentials for the display name, I was using the exact same case as shows up when I display the attributes using ldp. This showed the display name as being ADAMAdmin. I didn't try using all lower or all upper case.

I'm also using multiple threads. The tool allows you to set the thread count as an input and the best performance I got was at 4 threads. After that, it fell off of bit.

We had thought about using LDIFDE but decided against it for two reasons: 1) can't do secure passwords if they have to be stored in a text file; 2) managing huge text files may be problematic as we're going to be uploading 1-2Million users.

Anyway, thanks again for your help.

-Dave

It would be interesting to try to figure out why Digest auth didn't work, but at the same time if you have no plans to use it otherwise, it probably isn't worth a significant investment of time either.

Good luck with the project.  It sounds like you are in good shape at this point.