That's a different question. You're talking about securing directory information.
LDAP is a DIRECTORY SERVICE, and by design, is intended so that anyone with the appropriate credentials can view certain types of information by default. Such as, yes, their username, email address and so on.
Some of that information must absolutely be available to all objects in the directory - you can't authenticate if your username is not readable. You can't get access to an application controlled by group membership if the membership of that group can't be
read.
That said, you can place security constraints on many objects and attributes in AD. Firstly, attributes that aren't in the base schema can be marked as "confidential", which immediately removes Read from Authenticated Users (which is added to attributes
by default). From there, you could configure permissions so that members of a certain group could not read certain account attributes. You could lock down the "department" attribute (and many other attributes) on all or selected user accounts
so that only certain users could read that (although if Exchange uses it to build address lists or distribution groups, you'd want to be careful of that). You could configure groups so that viewing their memberships is denied to certain users or groups. You
can create custom attributes in the AD schema with custom permissions.
There are many ways of securing data in AD. So to imply that it's all wide open if port 389 is accessible is incorrect. But by default, and this is true of most LDAP implementations, a certain set of attributes are readable to all other authenticated users.
It's up to you as an administrator to understand that default attribute set and mitigations if certain data is sensitive (and
genuinely sensitive, not some manager complaining that other internal users can see his account name. Please.)
The main thing that bugs me about the AD implementation of LDAP is that we can't force a simple LDAP auth (rather than SASL) to only be available over LDAPS. Most LDAP binds will be authenticated via SASL in a Windows environment, so why can't we lock down
the auth part of LDAP?
