Microsoft's Active Directory Security Features

New and updated features since Windows Server 2003 (without SP1)
Windows Server 2003 operating systems with Service Pack 1 (SP1) offer the following improvements (compared to Windows Server 2003 without SP1) that help provide increased levels of support for Active Directory:

Improved replication and DNS diagnostic testing capabilities
Active Directory® has been updated to provide automatic directory service backup reminders, improved protection against replication errors, improvements to Install from Media (to facilitate adding new domain controllers that are DNS servers), improved DNS diagnostic testing capabilities, and access to a new platform for running domain controllers in virtual machines under Microsoft® Virtual Server 2005. For more information about these and other new Active Directory features and enhancements, see New features for Active Directory.

New and updated features since Windows NT 4.0
The Windows Server 2003 family offers the following improvements (in comparison to Windows NT 4.0) that help provide increased levels of support for Active Directory:
Simplified user and network-resource management
Using Active Directory, you can build hierarchical information structures that make it easier for you to control administrative credentials and other security settings and that make it easier for your users to locate network resources, such as files and printers.

Flexible, secure authentication and authorization
Flexible and secure authentication and authorization services provide protection for data while minimizing barriers to doing business over the Internet. Active Directory supports multiple authentication protocols, such as the Kerberos V5 protocol, Secure Sockets Layer (SSL) v3, and Transport Layer Security (TLS) using X.509 v3 certificates, and security groups that span domains efficiently.

Directory consolidation
You can organize and simplify the management of users, computers, applications, and devices, and make it easier for users to find the information they need. You can take advantage of synchronization support through Lightweight Directory Access Protocol (LDAP)-based interfaces, and you can work with directory consolidation requirements specific to your applications.

Directory-enabled applications and infrastructure
Active Directory features make it easier for you to configure and manage applications and other directory-enabled network components.

Scalability without complexity
Active Directory scales to millions of objects per domain and uses indexing technology and advanced replication techniques to speed performance.
Use of Internet standards
Active Directory provides access through LDAP and uses a Domain Name System (DNS)-based namespace.

A powerful development environment
Active Directory provides a powerful development environment through Active Directory Service Interfaces (ADSI), which provides an object-oriented interface to Active Directory. ADSI makes it easy for programmers and administrators to create directory programs by using high-level tools such as Microsoft Visual Basic, Java, C, or Visual C++, without having to worry about the underlying differences between the different namespaces. For more information, see Programming interfaces.

Replication and trust monitoring
Active Directory provides Windows Management Instrumentation (WMI) classes to monitor whether domain controllers are successfully replicating Active Directory information and whether trusts are functioning properly.
Message Queuing distribution lists
Message Queuing (also known as MSMQ) enables you to send messages to distribution lists that are hosted in Active Directory.

New and updated features since Windows 2000
The Windows Server 2003 family offers several improvements (in comparison to Windows 2000) that help provide increased levels of support for and better management of Active Directory. For a list of the Active Directory features that are new in this release,

LDAP Security Features

Remote Communications : Remote communication security may or may not be an issue. If you provide unlimited (anonymous) access to non-sensitive LDAP data then the security issue is moot. Caution: In these circumstances you potentially become vulnerable to DoS/DDoS attacks through malicious LDAP query loads - so even this apparently trivial environment may need careful consideration. If all LDAP communications can be guaranteed to occur within a trusted network then you may elect to operate with simple cleartext passwords without additional security. However even in these cases it may be a simple matter, depending on the trusted network topology, to sniff traffic and either inspect sensitive data or obtain passwords sent in the clear.
When communication occurs across an untrusted network then snooping, sniffing, man-in-the-middle and other possibilities provide endless hours of fun for wannabee attackers. Also bear in mind that the growing emphasis on run-time configuration (RTC) (a.k.a cn=config) and monitoring (cn=monitor) it may become increasingly the norm that LDAP browsers become the remote consoles for administering LDAP servers. This traffic is, by its very nature, highly sensitive.
Assuming that some level of security is required the first question to be addressed is - do I need to protect only passwords or do I need to protect data and passwords ? Depending on the answer to that question will determine the next step.

Passwords : Securing passwords during communications should not be confused with securing them within configuration files or DITs. Even if you have secured all passwords within the configuration file or the DIT using a hash-method, such as {SSHA}, when a password is sent from a client to the server it is sent in the clear, hashed at the server and compared with the stored contents. Without any further action it can therefore be snooped (or sniffed depending on your predilection for these terms). Note: When an entry containing, say, a userPassword attribute stored using, say, {CRYPT} is requested by a client it is not sent in cleartext but in its hashed (stored) form. However when access to that same entry is required the client sends the authenticating password in cleartext and clearly if the login is successful the snooper can reasonably assume the cleartext password was correct!
When hashed passwords are sent in a snoopable data stream they can become vulnerable to a dictionary attack - the attacker has the hashed form and runs a list of passwords (a dictionary) through the hashing algorithm until a match is found. Using salt (one or more octets - depending on the implementation - are added to the password before hashing and removed before comparison) significantly improves the security of hashed passwords and unless there are good reasons for not doing so the salted form of any hashing algorithm should always be used. ACLs should be used to limit access to passwords other than specifically authorized users. For example assuming a userPassword attribute the following ACL will only allow the attribute to be sent to the owner of the entry or a specific (admin) group of users. if only sswords require to be safeguarded then the solution is to use SASL with an ALGORITHM such as CRAM-MD5 which performs a secure handshake (using a shared secret) and during which dialog the password never appears in cleartext ( SASL configuration examples). The alternative is to use SSL/TLS (with or without SASL) or Kerberos 5/4. In this case simple password mechanisms can be used since the whole communication stream is encrypted and therefore snoop-proof.
Finally overlay policy provides features to control aging, complexity and mandatory resets as well as other characteristics of the passwords being used.

Data : If the data originating from an LDAP server needs to kept snoop-proof then the only solution is to encrypt the entire data stream using SSL/TLS (with SASL or without SASL) or Kerberos (SASL). The down-side to this approach is that encryption is a CPU intensive process and if resource usage or performance is a major consideration then the choice of bulk encryption methods available within the SSL/TLS suite becomes very important (configure SSL/TLS and configure SSL/TLS via SASL). It is possible to mix and match communication. If, for example, it is deemed adequate to use simple cleartext passwords (or even run anonymously) for normal remote LDAP access but additional protection is required when running certain classes of users (configuration samples for mixed SSL/TLS/ and SASL access).

While the discussion so far has concentrated on merely gaining access to data - what about changes and modifications to that data? OpenLDAP provides two capabilities to generate audit information. The overlay auditlog (more info use 'man slapo-auditlog') and overlay accesslog both provide features to log changes to the underlying DIT and accesslog even provides capabilities to record binds and read/search access as well as save previous contents of entries or attributes.

Local Access : Local access is defined to be any event that occurs within the LDAP server or server cluster (or through secured remote access such as provided by ssh) and includes most obviously config files and locally issued commands .

Config Files : There are two components to be considered here:
Ownership and permissions: By default modern LDAP systems run with low privilege user/group accounts (normally ldap:ldap). OpenLDAP does an excellent job with its config file, slapd.conf which can contain some highly sensitive data. OpenLDAP loads with root permissions (to allocate privileged ports) before dropping down quickly to its normal (low) operational privileges: before doing so it ensures (changing if necessary) that slapd.conf is owned by ldap:ldap (or the user:group it is running under) and has permissions of 0600. This prevents the worst excesses of accidental disclosure.

Passwords: Passwords that appear in the config files and slapd.d directories (for cn=config use) tend to be especially sensitive such as rootpw. Consideration can be given to removing them completely once a DIT has been established or at the very least storing them as hashed values to prevent trivial disclosure. Unfortunately using an include file to store the most sensitive data with very tight permissions (such as root read-only) and which can be used with a number of other systems offers no benefits since OpenLDAP has already dropped to its low operational privilege before assembling slapd.conf. However as described above OpenLDAP already has an excellent file permission modification mechanism so this wheeze is superfluous.

Commands (: Historically LDAP was administered using a local, mostly command line, interface. It was also reasonable to assume that local (in-server) traffic was not snooped making simple (cleartext) password protection to most administrative services an adequate security measure. However, as noted above, the increasing emphasis on run-time configuration (RTC) (a.k.a cn=config) and monitoring (cn=monitor) may mean that remote LDAP Browsers become the norm for LDAP system administration. In this case access to these services will transmit highly sensitive data which should be protected using data security techniques such as SSL/TLS.

Finally, since the RTC stores everything in a DIT (cn=config) it may be worth considering the use of the powerful features of overlay accesslog as tool to generate audit logging of changes to this DIT.

DIT : DIT security is defined with the LDAP Security model and is implemented exclusively through the use of the access to directive of slapd.conf or the olcAccess attribute when using run-time configuration (RTC) (a.k.a cn=config).

Replication : Even if normal client access to an LDAP system has a low security requirement the same may not be true for replication of that same DIT. During a replication cycle at some point or another all the data in a DIT (user and operational attributes) will be exposed on the communication network. Of necessity some of this information is very sensitive. Replication communications connections merit separate consideration. You can provide mixed SSL/TLS and other secure (or even insecure) connections in a single server (configuration samples for mixed SSL/TLS and SASL access).

X.500 security features

X.500 Directory Service is a standard way to develop an electronic directory of people in an organization so that it can be part of a global directory available to anyone in the world with Internet access. Such a directory is sometimes called a global White Pages directory. The idea is to be able to look up people in a user-friendly way by name, department, or organization. Many enterprises and institutions have created an X.500 directory. Because these directories are organized as part of a single global directory, you can search for hundreds of thousands of people from a single place on the World Wide Web.
The X.500 directory is organized under a common "root" directory in a "tree" hierarchy of: country,organization, organizational unit, and person. An entry at each of these levels must have certain attributes; some can have optional ones established locally. Each organization can implement a directory in its own way as long as it adheres to the
Learn More
Networking Resources
basic schema or plan. The distributed global directory works through a registration process and one or more central places that manage many directories.
Providing an X.500 directory allows an organization to make itself and selected members known on the Internet. Two of the largest directory service providers are InterNIC, the organization that supervises domain name registration in the U.S., and ESnet, which maintains X.500 data for all the U.S. national laboratories. ESNet and similar providers also provide access to looking up names in the global directory, using a number of different user interfaces including designated Web sites, whois, and finger. These organizations also provide assistance to organizations that are creating their own Directory Information Tree (DIT).
In X.500, each local directory is called a Directory System Agent (DSA). A DSA can represent one organization or a group of organizations. The DSAs are interconnected from the Directory Information Tree (DIT). The user interface program for access to one or more DSAs is a Directory User Agent (DUA). DUAs include whois, finger, and programs that offer a graphical user interface. X.500 is implemented as part of the Distributed Computing Environment (DCE) in its Global Directory Service (GDS). The University of Michigan is one of a number of universities that use X.500 as a way to route e-mail as well as to provide name lookup, using the Lightweight Directory Access Protocol (LDAP).

GPRS Security Feature, Threats and Solution

The network architecture of GPRS [3] is presented in Fig-
ure 1. A GPRS user owns a Mobile Station (MS) that pro-
vides access to the wireless network. From the network
side, the Base Station Subsystem (BSS) is a network part
that is responsible for the control of the radio path. BSS
consists of two types of nodes: the Base Station Controller
(BSC) and the Base Transceiver Station (BTS). BTS is
responsible for the radio coverage of a given geographi-
cal area, while BSC maintains radio connections towards
MSs and terrestrial connections towards the fixed part of
the network (core network).

The GPRS Core Network (CN) uses the network el-
ements of GSM such as the Home Location Register
(HLR), the Visitor Location Register (VLR), the Au-
thentication Centre (AuC) and the Equipment Identity
Register (EIR). HLR is a database used for the man-
agement of permanent data of mobile users. VLR is a
database of the service area visited by an MS and contains
all the related information required for the MS service
handling. AuC maintains security information related to
subscribers identity, while EIR maintains information re-
lated to mobile equipments’ identity. Finally, the Mobile
Service Switching Centre (MSC) is a network element re-
sponsible for circuit-switched services (e.g., voice call) [3].
As presented previously, GPRS reuses the majority of
the GSM network infrastructure. However, in order to
build a packet-oriented mobile network some new network
elements (nodes) are required, which handle packet-based
traffic. The new class of nodes, called GPRS support
nodes (GSN), is responsible for the delivery and routing
of data packets between a MS and an external packet data
network (PDN). More specifically, a Serving GSN (SGSN)
is responsible for the delivery of data packets from, and
to, a MS within its service area. Its tasks include packet
routing and transfer, mobility management, logical link
management, and authentication and charging functions.
A Gateway GSN (GGSN) acts as an interface between
the GPRS backbone and an external PDN. It converts
the GPRS packets coming from the SGSN into the ap-
propriate packet data protocol (PDP) format (e.g., IP),
and forwards them to the corresponding PDN. Similar is
the functionality of GGSN in the opposite direction. The
communication between GSNs (i.e., SGSN and GGSN) is
based on IP tunnels through the use of the GPRS Tun-
nelling Protocol (GTP).

In order to meet security objectives, GPRS employs a set
of security mechanisms that constitutes the GPRS secu-rity architecture.

Most of these mechanisms have been
originally designed for GSM, but they have been modi-
fied to adapt to the packet-oriented traffic nature and the
GPRS network components. The GPRS security architec-
ture, mainly, aims at two goals: a) to protect the network
against unauthorized access, and b) to protect the privacy
of users. It includes the following components [11]:
• Subscriber Identity Module (SIM);
• Subscriber identity confidentiality;
• Subscriber identity authentication;
• User data and signaling confidentiality between the
MS and the SGSN;
• GPRS backbone security.

GSM Security features, threats and solutions

GSM (group special mobile or general system for mobile communications) is the Pan-European standard for digital cellular communications. The Group Special Mobile was established in 1982 within the European Conference of Post and Telecommunication Administrations (CEPT). A Further important step in the history of GSM as a standard for a digital mobile cellular communications was the signing of a GSM Memorandum of Understanding (MoU) in 1987 in which 18 nations committed themselves to implement cellular networks based on the GSM specifications. In 1991 the first GSM based networks commenced operations. GSM provides enhanced features over older analog-based systems, which are summarized below:

Total Mobility: The subscriber has the advantage of a Pan-European system allowing him to communicate from everywhere and to be called in any area served by a GSM cellular network using the same assigned telephone number, even outside his home location. The calling party does not need to be informed about the called person's location because the GSM networks are responsible for the location tasks. With his personal chipcard he can use a telephone in a rental car, for example, even outside his home location. This mobility feature is preferred by many business people who constantly need to be in touch with their headquarters.

High Capacity and Optimal Spectrum Allocation: The former analog-based cellular networks had to combat capacity problems, particularly in metropolitan areas. Through a more efficient utilization of the assigned frequency bandwidth and smaller cell sizes, the GSM System is capable of serving a greater number of subscribers. The optimal use of the available spectrum is achieved through the application Frequency Division Multiple Access (FDMA), Time Division Multiple Access (TDMA), efficient half-rate and full-rate speech coding, and the Gaussian Minimum Shift Keying (GMSK) modulation scheme.

Security: The security methods standardized for the GSM System make it the most secure cellular telecommunications standard currently available. Although the confidentiality of a call and anonymity of the GSM subscriber is only guaranteed on the radio channel, this is a major step in achieving end-to- end security. The subscriber’s anonymity is ensured through the use of temporary identification numbers. The confidentiality of the communication itself on the radio link is performed by the application of encryption algorithms and frequency hopping which could only be realized using digital systems and signaling.

Services: The list of services available to GSM subscribers typically includes the following: voice communication, facsimile, voice mail, short message transmission, data transmission and supplemental services such as call forwarding.