The news regularly has stories of security breaches on websites. Having worked with identity security for years, I have seen a lot of mistakes made that are really easy to avoid simply by making security an essential part of the planning process. Two things to consider in the security of the site are how you are going to store and secure the identities, and how the security model will be built and enforced consistently on the site.
Use a solid LDAP directory
Let's first tackle the identity store. This is the backend that will hold all the identity information on users of your site. Think about when you log into say Amazon, or Google, or your companies internal social media site. The website needs to know about you, and every other users. It will need to store user name and password at the very least. Often you will want to store mailing address and email address, maybe a phone number. For the company site you might store the employees department, their employee number, the managers name, and what location they work. All of this is stored in the directory. Often when I read of security breaches the cause was because of a SQL database breach. If you use an SQL database then you need to build all the security around the database from scratch.
There is a better solution than using a basic SQL database. There are directory products that are designed from the ground up to be secure identity stores. Some examples of these would include NetIQ eDirectory, OpenLDAP, and Microsoft Active Directory. Under the hood these are all databases. However, the structure of the database is designed specifically to store identities, and to easily set security rights to who can see what in the directory. And they have stood the test of time for being rock solid identity stores. Make sure you have a person versed in the particular directory product you decide to deploy. Like SQL, LDAP is a common language that is cross platform, this time specifically for access to identity directories. The directory will have a full suite of features for setting up security in the directory from who can access what information on different identities, to being able to have groups for people to be assigned to, and even how many user entries can be retrieved at one time. It also will have the ability to have multiple servers with the same information for automatic fail over in case of server issues.
Use a web security product to lock down the site
A lot of times web developers will write their own security on the site. They will write login pages, and use processes they write to enforce security. The challenge here is you have a person who's specialty is writing web pages trying to design a security infrastructure into that same site. In the process they have to constantly keep in mind all the different possible ways an attacker might breach the system and write programming to prevent it. The web designer needs to find all the possible holes in the site. The attacker only needs to find one way in.
The alternative is to use a program that is designed to protect the web site from outside of the website. Examples of this would be products like CA Siteminder, Oracle Access Manager, or NetIQ Access Manager. Using an access management solution moves the security workload out of the hands of web designers and into the hands of security engineers. The software is designed specifically to protect sites while at the same time making access as easy as possible for users. The software is designed to also give the ability for a single sign on experience in an enterprise so that a user can log into one website and subsequently access many other sites in the same organization.
When you are getting ready to deploy a new website you need to make sure to bring in your security engineers right up front to help with the design of the site. The structure of the site can significantly impact how easy it is to design the security model around it. It is much easier to secure a site if sections of the site are laid out in a specific way. There might be certain sections of the site which should only be accessed by a subset of the user population. If the pages of those sections are in their own subdirectory then it is very easy to design the policy to restrict that whole section of the website to a particular group or groups of users as listed in the LDAP directory. If those pages are scattered all over then it becomes much more difficult to secure.
So how does the access management software work? Well it sits in front of the actual website. When a person tries to get to the site then the AM software will intercept the request and evaluate the user trying to access it. The AM software will be responsible for requesting the credentials from the user and verifying them. Once they user is authenticated the AM software will let them in. That is the first step, authentication. Once the person is authenticated in the AM software could just let them in if they will have access everywhere. Otherwise the AM software will next take on the role of approving or denying authorization to the particular part of the system the user is trying to get to.
The main home page of the system typically will be available for all users of the system. So once a user is authenticated in they will simply be allowed to the site on the home page. They also will most likely be able to get to the help pages, the about pages, and the contact information pages. So there will be no need for authorization on those pages either. But there might be a section that is specifically for only managers. For that section you might create an LDAP group called managers. The AM product will then have a policy that will say only if you are a member of the managers group will you have access to this section of the website. Another section of the site might be limited to people in the finance and accounting departments. So the users could be in a group called finance, and the AM policy would be set to only allow users in the finance group to those pages.
As we look at these hypothetical examples you might start to see why good planning up front is important. If you can collect all the pages and code for a particular part of the site in the same space then as you create new pages all you have to do is put them in the same subdirectory and they will automatically be protected with the same protection as all the other pages. If you put all the pages in the same place, or spread them all over the site then you will have to specify each of the pages individually for the proper protection. As new pages are created the web designers would need to make sure to inform the access management administrators of the addition so that they can be granted the proper protection. The more difficult the security model is the more of a chance of creating holes that an attacker can breach. Complexity always leads to poor security.
Along with being the traffic cop over the websites of the organization, a solid access management software program will also give solid auditing features. In recent years monitoring access and being able to answer auditors questions has become more and more important. Also, if there is a suspected breach it is vital to know who did get in, and what they got access to. You need to be able to determine what information might have leaked out of the organization. And you need to be able to have the evidence to take care of the situation. You also need to know if someone is attempting to get to a place on the system they are not supposed to so you can respond appropriately.
Products like Siteminder, Oracle OAM, and NetIQ Access Manager will keep logs of all the authentications and authorizations that were approved, and where on the site they were allowed, listing who accessed what. They will also record any denied authentication or authorization attempts. There are even programs like NetIQ Sentinel that can monitor these logs and watch for suspicious activity. Obviously there will be times a person accidentally stumbles on the wrong page of a site and gets denied. However, if the log starts to show a flood of repeated authorization denials to a particular part of the site by the same user account, or a sudden increase in denials by a lot of accounts, then it is important to be notified of this and be able to react. So a program like Sentinel can monitor the logs and look for that suspicious activity. Then you can have rules in place for notification of the suspicious activity. You can set up for email alerts, pages, and even escalation if something is not dealt with in a timely manner.
It is important to also set up a process for storing those logs for an extended period of time. Some of the vendors will have add on products to deal with the logs over time. These products will parse the log files into some sort of database that can then be searched and reported on. Or it is often possible to have a script that would retrieve the logs and push them into a SQL database. Once there they can be easily searched and reported on. Now if you end up suspecting a breach by an employee you can go back and find proof where they were on the site. This will give you the solid evidence you need to deal with the situation and the user.
Some final notes on network design
When you are laying out the system there are a few things to consider in the design of the overall system. First is the placement of the LDAP directory. Typically you will not want your directory exposed to direct access by users. So the directory should be at least on an internal network segment behind a firewall. Typically the websites that are Internet facing will be in the DMZ, or possibly behind a proxy. There are several ways to set that part up. But the LDAP servers need to be behind that. It is not a bad idea to maybe even put the LDAP servers in their own network island behind a firewall inside the internal network. If you want users to access directory information they should use some sort of website that would offer that up. Often they will use the directory in their email program. But there could also be a protected website (yes using an AM product to protect it) that would present them with access to the directory. Identity information is very important to protect from access. The LDAP servers should also be set up to prevent wholesale extraction of data too. It is possible in most LDAP directories to set up servers so they won't return more than a particular number, say 100 entries, to a wildcard search. It is also possible to set up a timeout limit too. Think of all the important information being stored in the directory. This will help prevent your organization ending up on the news. Some people might have a need to get reports on the entire directory, and for that you can set up a single server in the cluster of servers that would allow that access. Again, limit access to that server to a very specific set of people.
Another thing to consider is the setup of the different parts of the AM solution. Many of those solutions have multiple servers or parts that make up the solution. Put only the parts that you need to into the DMZ. The rest of the solution should be on the internal network segment. The guiding rule should be least access. You want to make sure that the most critical parts of your infrastructure are better protected. So for example with Siteminder you will want the policy servers on the internal network while the web agents are of course on the web servers in the DMZ. You will want to limit access to any identity and access management system to the smallest group of people possible.
There is a new wireless networking standard out that gives impressive improvements over the older technology. The standard is called 802.11ac. With all the new multimedia uses of wireless networks demanding more and more data be streamed in real time the speed increase could not come fast enough. We have moved beyond the days of simply viewing static websites with some images on them. More and more people are watching YouTube videos, listening to audio streams from Pandora, Spotify, or Apple Music, or watching movies and television shows on things like Hulu, Netflix, and Amazon Prime. Gamers want low latency connections for real time gaming too. The new 802.11ac wireless networking can affordably bring this to you.
802.11ac works in the 5 GHz frequency. This allows for faster throughput. It is also fully backward compatible with the earlier 802.11n and 802.11g technology. The 802.11n specification had a maximum theoretical throughput of 300 Mps. The newer 802.11ac will go from 433 Mpbs up to several gigabits per second. This means that 802.11ac networking is faster than a USB 2.0 connection, and potentially just as fast as a USB 3.0 connection. Now wireless access to NAS, or network attached storage, can be just as fast as a wired connection to those same hard drives. As people move more and more from using desktop computers to laptop computers NAS storage becomes more and more useful. You can be anywhere in your home or office and have access to massive amounts of storage that is also very fast to access.
How 802.11ac Works
So how do they pull off all of this magic? Well first 802.11ac works exclusively in the 5GHz spectrum. The 2.4 GHz spectrum is way overcrowded with all sorts of wireless devices from baby monitors to security cameras, as well as older standard wireless networking. And even 802.11n used both 2.4 GHz and 5 GHz. So the engineers realized they needed to stay exclusively on the more wide open road of 5 GHz to push all that data over.
Second, 802.11ac uses up to eight spatial streams (MiMO technology). 802.11n only was able to use up to 4. So this allows a much wider footprint to push all that data through. The channel width for 802.11n was 40 MHz wide. The 802.11ac standard is 80 MHz and those can be doubled to 160 MHz. So you are looking at a difference of 4x40MHz compared to 8x160MHz.
Third, 802.11ac implements beamforming. The 802.11n standard had it but it was not standardized between vendors. What beamforming does basically is allows the router to focus where it is transmitting the power so that more of it gets to your device. It basically looks for your device and focuses the energy your way. This can boost throughput and improve signal quality.
Obviously to make use of the new standard you will need a new 802.11ac router. Your networked devices will also need to support the 802.11ac standard. For desktop computers you can simply replace the existing network interface card. For laptops you would need to get some sort of USB attached network adapter. You would have to research about if there is a way to upgrade other devices on your network. Rest assured that newer devices will be coming out that support 802.11ac wireless networking. If you are buying new network attached devices you should make sure to ask if they support 802.11ac wireless networking!
If you have never used an LDIF file before to manage a directory then you are in for a treat. If you are looking for techy information on how to build out an LDIF, including examples, then just look a little lower here.
So what is an LDIF file? An LDIF is a text file that you can feed into a directory to add, delete, move, or modify objects in the directory. You can adjust users, groups, and containers in the directory. If you are doing a single user then it might be easier to use any GUI tool you have available to do that request. But if you are doing a number of users, or need to do the exact same change on a number of trees, then an LDIF will make your life much easier. This is also a really great way to level set the information in different trees or on different objects in the same tree that should all have the same attribute settings.
When you do a command line LDAP search on a directory the results that the command gives is in LDIF format. If you redirect that output to a file then you can use that as a base or template for building out your LDIF file. I will give some examples of this at the bottom of the page. Keep in mind though that the ldapsearch command output is limited to a max of 80 characters across (and a lot of implementations go only 78 characters). So if you output a listing where some attributes give more than 80 characters of information then you will have line wraps that you need to deal with on creating an LDIF for input.
Several things to keep in mind with LDIF files. First, just like ldapsearch LDIF commands are case insensitive. You can use upper case, lower case, or mixed case. As far as the attributes themselves though, however you type them into the LDIF is how they will show up in the directory, and how they will display on output of a search. So if there is a particular need for case in the attribute you need to be mindful of that in creating your LDIF. Sometimes certain programs are written expecting a certain case for the attribute, and you need to put it in using the same case. Some people will use mixed case in a way to make names easier to read. If you want that then put it in that way in the LDIF. But the ldapmodify program will not care what the case is that you use.
Any line that starts with the pound or hash sign is considered a comment and will be ignored when the file is processed.
# This is the comment line and can be used to section things or note info
Trailing Spaces and Line-folding
You will want to make sure that there are no trailing spaces on any lines. The only time that trailing spaces are allowed is when you are line-folding an entry. If you have information that is going to be on two lines for a single attribute entry then you need to have a trailing space on that line and a single space at the beginning of the next line. The LDIF parser will then remove the spaces and concatenate the two lines.
End of record and multiple modify option separators
One other big gotcha that a lot of people get hit with is lacking a blank line at the end of each record. Every entry in an LDIF file needs to have a line with no spaces to end it. It is just a blank line with a carriage return. The file needs to end with a final clean carriage return too. You also need to be careful if you create the file in an editor on a Windows computer and then copy the file to a Linux or Unix server to run. It is possible you will not have the proper carriage return codes in the file for the *nix system since Windows uses different codes for carriage returns than *nix by default. A lot of text editors on Windows have a setting for using *nix returns.
If you are doing a modify on one or more records and are doing multiple operations on each object you need to separate the different operations with a hyphen. Look below to the modify section for examples of this.
The Big DN
Every item or object in the directory that you are going to modify is known by their DN. This is the fully qualified name of the object in the tree. This will be the first line for any record in the LDIF file that you are updating. The DN will be in LDAP format. The line will start with dn: and then have the full DN of the object. This is NOT case sensitive. If you are dealing with containers then the beginning of the DN will not start with cn= but will start with the type of container like ou= instead. Of course, make sure there is no trailing spaces in the line, just like all other lines or you will get an error.
Pushing the LDIF into the system
There are several ways to push an LDIF file into a system. Probably the most generic is to use the ldapmodify command. This is available on all *nix and Mac systems. You can find it for Windows too. If you are going against AD then you can download Microsoft's LDIFDE program to push the file in too. Some other environments have additional tools they make available to push the file into the system. The most basic ldapmodify line to accomplish this is:
ldapmodify -h hostname -D FQDNAdmin -w password -f filename.ldif
If you use this and there is a record that has an issue and throws an error then the processor will stop pushing entries and throw an error on the screen. If you want the program to keep processing records beyond the one that has the error then you can use a -c in the command line too. I will show an example later where this is very handy on a modify.
Note on system differences (and disclaimer)
LDAP and LDIF are supposed to be standards. But not everyone implements everything exactly the same way. You will find some slight differences between implementations. It is always good to test your LDIF files in a test directory before jumping in and going all gung ho in your production system. It is expected that you will use all due diligence in making sure you have a good LDIF file and will be updating your particular system the way that you are expecting to update it. One way to know how your particular system handles ldifs is to do an ldap search and export the information to a file. Command line ldap search programs will output in ldif format.
Adding objects to the system
If you want to add new users, groups, organizational units etc. then you need to perform an add operation. You designate the change type of an LDIF record with the changetype: line that goes right below the DN of the object you are adding or modifying.
With an add you need to make sure that you include the objectclass of the object you are creating. For most systems you should only need to specify the base class of the object and the system should fill in any additional entries. But I don't like leaving that to chance. So my recommendation is to do an ldapsearch for an object like the type you want to add and then copy the objectclass section right out of the export. That way you get all the objectclass lines for the new object.
Second, you MUST put in all required attributes of the object. You don't have to list any optional attributes unless you want to populate them. But you need to have the required attributes specified. This is something that will be different on various systems and platforms. Go into the definition of your class in the schema to determine what is required for any particular object class.
So let's make a couple users now. Let's make Clara Oswald and Bob Cratchit.
fullname: Clara Oswald
fullname: Bob Cratchit
Each attribute gets a line that starts with the name of the attribute ending in a colon followed by a space then the value you want in the attribute. If the attribute is a multivalued attribute and you want to put in multiple entries then simply use the attribute name several times and it will add each entry to the array in the attribute. If you have a binary entry then you will need to encode it in Base64.
I would recommend you export a user in ldif format using ldapsearch to see all the attributes that are populated for them. This is especially true with what objectclasses they should have. Most systems will not export the password. This will help in knowing how to format the entries for the new users to add.
Two things to note here too. First, the uid and the cn are different attributes and can be set to different values. Often they are set the same, but nothing prevents you from setting them to different values. And since they are different attributes they both need to be set.
Second, and this is a little known bit of information, the cn attribute is actually a multivalued attribute (at least on the systems I have tested it on). Typically you will only ever see a single value in it. But it is possible to stuff more than one in there. Most programs will only ever read the first value in the array (multivalued attributes present to programming languages as arrays). So if the one you really want is the second or third in the array you could find some really odd behavior in your program. This becomes more important in the modify change type that we will talk about below.
You can add a container in basically the same way. Let's do an OU.
Pretty simple eh? List out the attributes and the values for each one below the first two lines of the record, make sure there are no trailing spaces, and that you have a clean blank carriage free line at the end of each record in the file. If you are setting up a test tree and want a large number of records to test with then you can use a bash script, VBScript, or PowerShell program (or language of your choice) to generate the file using some sort of cool algorithm to generate all the names and passwords, then simply push the file in.
Often companies or organizations need to bring on board a number of people at the same time. Using ldif files can make that job much easier. In a future post I will show a vbscript that you can use to help easily make the ldif file to create users based on an Excel spreadsheet of users. It is often easy to get an Excel spreadsheet of the new users.
A future post will also show how you can modify existing users and groups and to delete objects in the tree.
I am truly a geeks geek. I have worked in computers for over three decades. I have worked on mainframes, Unix systems, Linux before almost anyone knew what it was, and many other systems. I love computers, and love making them do things people think is impossible.