CP582 Naming
Browsing X.500
The tool we are using for this exercise is an LDAP Browser which is a minor adaptation of a Sun demo program. As you will see it looks very similr to the NFS browser that was used in week 9 – this is because the display portion of the program uses the Java JNDI ( Java Naming Directory Interface ) to manipulate a variety of hierarchical "name spaces". In week 9 the hierarchy was accessed via NFS – this week the access is via LDAP.
The objects of the exercises here are:
To get some familiarity with using the X.500 DIT from a user point of view - finding out a variety of peculiar information
To confirm that all interactions are via the original DSA that the browser is configured to contact. Even when you browse a distant location the information is still returned to you via your original DSA
To inspect the contents of LDAP request and response packets.
To realise that the X.500 DIT is not in a very complete or well implemented state. The second exercise where LDAp is used to browse non-X.500 servers runs a lot more smoothly.
What to do:
Basic LDAP browsing - what server are we talking to
Start NetXRay and create a filter that will capture LDAP packets. LDAP is not one of the protocols that shows up in the Advance filter screen but if you create a Data Pattern filer that captures packets to and from TCP port 389. (0x0185 ) this will have the same effect. Ask your tutor if you have trouble with this.
It is easy to set Data Pattern filters ( using the "Set Data" button ) if you already have a capture that is quite similar to the one that you want. Any capture file that uses TCP will be appropriate in this case. With the "almost right" capture open you can start to set up a data pattern filter, browse down through the packet until you find the item that yoiu want to filter on ( eg TCP destination port ) and use "Set Data". NetXRay will automatically set all the tricky values - position in packet for example - but the value being filtered for will not be the right one. You can modify the value, as we did in an earlier lab, the correct port for LDAP being 0x0185. Then say OK to your filter!
(((LDAPBrowserLaunch)))
Start a capture
Launch the LDAP Browser using the icon on your desktop and check that some packets are captured.
View your capture buffer. Note the IP address of the LDAP server that this information came from.
Bring up a DOS prompt and PING the IP address above. Use the -a option - this will tell you the DNS name of the machine that has this IP address. Note this down too.
Some LDAP puzzles
Some of these queries my take a considerable time to execute - be patient. However if you think that the browser has hung you can easily stop it by using <ctrl>C in the DOS window from which the browser was launched.
How many Organisations are listed in Switzerland ( c=CH)
Notice the objects at the bottom of the main list that have animal names. Look at the attributes of some of these objects ( use the magnifying glass button ) Notice that many attributes refer to DSP and DAP . The objects you are looking at represent the X.500 hosts that are providing the information you are viewing.
How many Organisational Units are listed for the Hong Kong University of Technology - (c=HK) ( It's Ok - don't worry about counting them all! )
What department does Bo Hu work for at this Uni
Use the torch icon to bring up the search dialog
Your "Search Filter" will be cn=Bo Hu
Select "subtree" as your search scope
Check "Return Object"
The Hong University is clearly an institution that has made a wholehearted commitment to LDAP ( or X.500 ) and to making its directory available worldwide – many other institutions have not gone this far. See what happens when you try to look at some others.
Some attributes are universal in X.500, such as "cn" (Common Name) whereas some may be locally implemented. The Hong Kong Uni uses a RoomNumber attribute for its user objects. Use a search to discover who works in Room Number 5020 ( Search with: RoomNumber=5020 )
Capturing & Decoding LDAP packets
This brings up a number of new issues in NetXRay and also teaches us something new about TCP. This section is based on querying LDAP in the University LDAP Server
Configure the LDAP Browser to look at the Uni LDAP server:
Click on the Screwdriver button to bring up the Configure dialog
Edit the entry in the "Property Value" column for the "provider url" to read "ldap://fs6.ballarat.edu.au" ( double-click to edit )
Enter "o=uob" in the "Root" field at the top of the form.
Use the "Apply" button to make these changes effective
See if you can find yourself ( hint – use "sn=<your surname>" – sn stands for surname )
Start with the Data Pattern filter described above ( packets to and from port 389 )
Start a capture and display the contents of o=uob ( to repeat this select o=uob and use the reload button in the browser toolbar )
How many packets did you capture
Because you are capturing packets in both directions you have more than 5 packets. If you modify the filter to only include packets from the LDAP port, and repeat the capture, you should be able to focus on the structure of the LDAP replies.
How many packets were captured
What are the TCP flags on the packets captured Are they what you would have expected
An aside on the Push flag (PSH) – Up until now it has been suggested that whenever data is being sent across a TCP connection the PSH flag will be set. As you will see when you do this exercise this is not the case.
RFC793 ( the RFC for TCP ) gives the full story - the PSH flag does nothing more than request that the data be immediately sent across the TCP connection.
Many servers, such as FTP servers, would push their data as matter of course and therefore this misunderstanding has not caused any problems so far. LDAP servers however behave differently and allow data to accumulate in the TCP layer and be sent at that layer's convenience. Consequently much of the data returned by a LDAP request is in packets with only the ACK flag set.
Look at the LDAP portion of the first LDAP packet in this capture and examine the structure of the LDAP portion of this packet. It consists of a MESSAGE block containing the name of an object and some attributes of that object. The "message ID" displayed is simply a count of the LDAP messages you have sent during your session.
Look at the second packet in your capture and read down through the layers of the decode ( keep clicking on the bottom "+" sign and moving down through the decode) until you get to the end of the decoded data.
Select the last piece of decoded data and notice its position in the raw data below. You will see that there is one remaining piece of data that did not quite fit into that packet – you are told that the data was supposed to be 12 bytes long but only 4 of these 12 bytes has been included in this packet.
Relate what you see in the Browser ( names of OU's ) to what you see in the decode and see if you can guess what the missing bytes should be before looking at the raw data in the third packet.
You should find the missing bytes at the beginning of the LDAP section of the packet but you should also see that NetXRay's decode is confused by this extra packet which is a continuation of the data in a previous packet. ( The description of the packet in the packet list is "Bind Response" when it should be "Search Response" ) NetXRay is treating each packet as if it was the first and only packet in a LDAP response. You are beginning to see some of the limitations in the decode facilities of NetXRay.
Using LDAP to access non-X.500 data
To complete this exercise you will Netscape.
Use Communicator/Address Book to bring up the Address Book window
The databases listed ( Netcenter, Verisign, InfoSpace ) are actually the large "people finder" databases that can be accessed through the Web but they also have LDAP front ends on them.
You can add to this list using File/New Directory. The correct settings to search the Uni are:
LDAP Server: fs6.ballarat.edu.au
Port = 389
Search root: o=uob
Use the "Search For" button to look for yourself or a friend.
Use NetXRay to confrm that LDAP is being used for the search and locate an old friend. Good luck!