How to get the AD LDAP DN name from an user

Some times we need to have the full distinguished LDAP name for an Active directory user.

There are at least two ways to accomplish this goal:

1st) Running the command dsquery user -name ADUSERNAME where ADUSERNAME is the name of the user on the AD

2nd) Running the command ldifde -f users.txt where all LDAP data from AD is dumped into the file named users.txt

Windows 2003 slow network application performance

I was bitten very hard for something that is quite hidden and took a while to figure it out.

Moved an application from Windows 2002 to Windows 2003, and in the moving process, services that where on the same machine moved to different machines, which in turn means that they would use the LAN to communicate between them instead of the loopback adapter.

Well just imagine an application running on top of the line servers (8 CPU’s, 10GB RAM) running slower than a six year old server…

The main clue that something was blocking the performance was that there was no CPU load. So the application was not processing anything, just waiting…

Or friendly tool http://www.wireshark.org/ started to bring some light on the issue. It seems that most of the times between packets namely the between the PSH/ACK and the answer took around 200ms. Again processing the application log files show a lot of processing time under 10ms and a “bump” around the 200ms mark.

To make a long story short… Despite of most of Windows server deployments being made on high speed networks on enterprise LAN segments, Windows 2003 has by default an TCP/IP algorithm called nagle active so it can save bandwidth on slow WAN links!!!!!

What does it mean? It means that Windows will reply right away with an ACK packet if it has data to transmit back, so it piggybacks the ACK with the data saving packets. If it has no data it times-out after 200ms and then sends the lone ACK packet… Meanwhile the 1/4s as passed by. Small number theory says that a lot of small numbers added up give on big number, hence seconds of pure slowness.

For all your LAN throughput can be used by your applications you need to switch off the 200ms delay:

Here’s how: http://support.microsoft.com/?scid=kb%3Ben-us%3B328890&x=11&y=13

After the above documented change, well the application just caught fire and ran like a rocket.

Update: Also check: http://support.microsoft.com/kb/898468

Update2: Also check: http://support.microsoft.com/kb/948496 -> This will disable some “features”…

Active Directory LDAP Errors

Something I’ve copied from here: http://forum.java.sun.com/thread.jspa?messageID=4227692

Thanks Dave!

Just to find it easily:

Common Active Directory LDAP bind errors:

80090308: LdapErr: DSID-0C09030B, comment: AcceptSecurityContext error, data 525, v893
HEX: 0x525 – user not found
DEC: 1317 – ERROR_NO_SUCH_USER (The specified account does not exist.)
NOTE: Returns when username is invalid.

80090308: LdapErr: DSID-0C09030B, comment: AcceptSecurityContext error, data 52e, v893
HEX: 0x52e – invalid credentials
DEC: 1326 – ERROR_LOGON_FAILURE (Logon failure: unknown user name or bad password.)
NOTE: Returns when username is valid but password/credential is invalid. Will prevent most other errors from being displayed as noted.

80090308: LdapErr: DSID-0C09030B, comment: AcceptSecurityContext error, data 530, v893
HEX: 0x530 – not permitted to logon at this time
DEC: 1328 – ERROR_INVALID_LOGON_HOURS (Logon failure: account logon time restriction violation.)
NOTE: Returns only when presented with valid username and password/credential.

80090308: LdapErr: DSID-0C09030B, comment: AcceptSecurityContext error, data 531, v893
HEX: 0x531 – not permitted to logon from this workstation
DEC: 1329 – ERROR_INVALID_WORKSTATION (Logon failure: user not allowed to log on to this computer.)
LDAP[userWorkstations: <multivalued list of workstation names>]
NOTE: Returns only when presented with valid username and password/credential.

80090308: LdapErr: DSID-0C09030B, comment: AcceptSecurityContext error, data 532, v893
HEX: 0x532 – password expired
DEC: 1330 – ERROR_PASSWORD_EXPIRED (Logon failure: the specified account password has expired.)
LDAP[userAccountControl: <bitmask=0x00800000>] – PASSWORDEXPIRED
NOTE: Returns only when presented with valid username and password/credential.

80090308: LdapErr: DSID-0C09030B, comment: AcceptSecurityContext error, data 533, v893
HEX: 0x533 – account disabled
DEC: 1331 – ERROR_ACCOUNT_DISABLED (Logon failure: account currently disabled.)
LDAP[userAccountControl: <bitmask=0x00000002>] – ACCOUNTDISABLE
NOTE: Returns only when presented with valid username and password/credential.

80090308: LdapErr: DSID-0C09030B, comment: AcceptSecurityContext error, data 701, v893
HEX: 0x701 – account expired
DEC: 1793 – ERROR_ACCOUNT_EXPIRED (The user’s account has expired.)
LDAP[accountExpires: <value of -1, 0, or extemely large value indicates account will not expire>] – ACCOUNTEXPIRED
NOTE: Returns only when presented with valid username and password/credential.

80090308: LdapErr: DSID-0C09030B, comment: AcceptSecurityContext error, data 773, v893
HEX: 0x773 – user must reset password
DEC: 1907 – ERROR_PASSWORD_MUST_CHANGE (The user’s password must be changed before logging on the first time.)
LDAP[pwdLastSet: <value of 0 indicates admin-required password change>] – MUST_CHANGE_PASSWD
NOTE: Returns only when presented with valid username and password/credential.

80090308: LdapErr: DSID-0C09030B, comment: AcceptSecurityContext error, data 775, v893
HEX: 0x775 – account locked out
DEC: 1909 – ERROR_ACCOUNT_LOCKED_OUT (The referenced account is currently locked out and may not be logged on to.)
LDAP[userAccountControl: <bitmask=0x00000010>] – LOCKOUT
NOTE: Returns even if invalid password is presented.

Weird .NET errors

I’ve come across some weird .NET errors in one Windows 2000 Server with .NET 1.1:

System.NullReferenceException inside the function System.Enum.System.IConvertible.ToBoolean;

Also System.ArgumentException creeps up.

The main issue here is that sometimes the application works, and some times it doesn’t. Also other applications that share the same web server show the same symptoms.

Another weird issue is that when one of the applications work, the other doesn’t work and vice-versa.

To cut a long story short, this boils down to an issue to the ADODB.DLL. Each .NET application has a BIN directory where sometimes there is an ADODB.DLL. If these versions mismatch each other’s application versions, the issue related above happens. Simple, right :)?

How to solve it? Well make sure that the several instances of ADODB.DLL is the same version on each application, OR remove ADODB.DLL from the BIN directory from each application and put it on the Global Assembly Cache (GAC). How?

1) Create a directory, for example c:\adodb

2) Move the version of ADODB.DLL to this directory

3) Make sure that there are no more instances of ADODB.DLL on your .NET applications

4) Stop IIS (iisreset /stop) and delete all the temporary files created on the Temporary ASP.Net Files folder of your framework installation (c:\winnt\Microsoft.Net\framework\v1.1.1432\Temporary Asp.Net files\)

5) Register the ADODB.DLL on the gac: gacutil /i c:\adodb\adodb.dll

6) Restart IIS, with IISRESET

Problem solved (I hope…)

What happens is that the first application that was hit, moved is version of ADODB.DLL to the assembly cache (temporary), and the other applications, due to version mismatch failed to work because of this…

Lesson learned: Make sure that your BIN directory has the same versions of each file for each application.