Frequently Asked Questions about MDS 2.1

Q: How does one generate multiple gatekeeper and user certificates as well as a few LDAP server certificates?

Write a wrapper script around grid-cert-request, to generate a key and a certificate request (each pair per machine/user can be specified in a separate file). Then mail each request separately to the ca@globus.org. This makes it easy for the Globus Certificate Authority (CA) to issue certificates and do bookkeeping without too much additional effort.

Look at the command line options in grid-cert-request given below: 

 %grid-cert-request [-help] [ options ...]

  Options:
    -cn <name>         : Common name of the user
    -gatekeeper <name> : Create certificate for a gatekeeper named <name>
    -host <name>       : Create certificate for a host named <name>
    -dir <dir_name>    : User certificate directory ['/nfs/v5/sridhar/.globus' ]
    -cert <file>       : File name of the certificate
    -key <file>        : File name of the user key
    -req <file>        : File name of the certificate request
    -nopw              : Create certificate without a passwd
    -int[eractive]     : Prompt user for each component of the DN
    -force             : Overwrites prexisting certificates

Q: How do I generate and where do I install the LDAP server certificate.  Also how do I distinguish between the gatekeeper certificate and LDAP certificate?

A server certificate is needed by the LDAP service in order to run.

To request a server certificate, use the grid-cert-request command: 

  grid-cert-request -cn ldap/<FQDN> 
                    -cert server.cert -key server.key
                    -req server.request
                    -nopw -dir certdir

where <FQDN> is the fully qualified domain name of the host that will run the LDAP server, server.cert is the required name of the server certificate file, server.key is the required name of the server key file, server.request is the required name of the server request file, and certdir is the name of a directory in which to store the certificate.

The key will be generated immediately and placed in certdir/server.key. The key file should be readable only by its owner. 

As seen in the request above, the LDAP server certificate will have "ldap" in the message.

Q: What is the security model for MDS 2.1?

MDS 2.1 uses OpenLDAP, which is based on LDAPv3. The security in OpenLDAP (as of version 2.0) is provided by SASL, which uses GSSAPI.

GSSAPI is a convenient generic interface for secure application development. By itself, GSSAPI does not provide any security. It relies on underlying technologies to provide the actual identity authentication and message protection services desired by applications communicating over a network. Such a security technology is called a GSSAPI security mechanism. Applications may install and request the use of particular mechanisms or use a default mechanism provided by the GSSAPI implementation.

The GSSAPI security mechanism developed for MDS 2.1 is GSI, which enables the use of Globus certificates and grid-map files to provide authorization services to information objects. At the present time, we have all-or-nothing authorization, depending on whether an entry exists in a grid-mapfile. However, with the incorporation of CAS (Community Authorization Service), we will soon be able to provide a fine-grained access control to objects.

A security mechanism is identified by a globally unique Object Identifier (OID). For example, the OID for GSI is 1.3.6.1.4.1.3536.1.1.

The main security enhancement to LDAPv3 (in comparison to LDAPv2) is that new authentication mechanisms have been added to the bind operation: password protection using a hash function, and certificate-based digitally signed token. These are fully compatible with the definitions found in X.509, so that an LDAP to X.500 gateway can pass them directly to the X.500 server. The protocol is extensible to allow for privately defined or future additional authentication mechanisms, including challenge-response and multi-stage binds, and the server can return credentials to the client.

A problem with LDAPv2 deployment was that the string syntaxes for certificates and certificate revocation lists (CRLs) were not reversible, and that it was not always possible to obtain the DER binary encoding of values with these syntaxes in order to be able verify signatures. In contrast, LDAPv3 clients can request to receive CRLs, certificates and distinguished names in binary (DER encoded ASN.1) form, which eliminates the ambiguity. 

Q: Do I need root access to install and run MDS 2.1?

Root access is needed if you want to set up MDS 2.1 to automatically start up at system boot time. This can also be requested of system staff.

Q: I have everything up and running, but when I try to do a grid-info-search I get an error message:

ldap_sasl_interactive_bind_s: local error
What's wrong?

In MDS 2.1, clients perform a GSI-GSSAPI bind to the MDS server. The error message seen above occurs if the client does not have a valid proxy, or: 

$ ./install/openldap/bin/ldapsearch -h 1linux -p 2167 -s sub -b
"o=Grid" "objectclass=*"

SASL/GSSAPI authentication started

ldap_sasl_interactive_bind_s: Local error

If the "-x" option is used, we get the following:

$ ./install/openldap/bin/ldapsearch -h 1linux -p 2167 -s sub -b "o-Grid"
"objectclass=*" -x

version:2

#
# Filter: objectclass=*
# requesting: ALL
#

# search result
search: 2
result: 53 DSA is unwilling to perform
text: access denied: gridmap lookup failed

# numResponses: 1

This occurs whether we turn anonymous bind on or off, and whether we have run grid-proxy-init or not. Also, the grid-mapfile, owned by root, contains:

"/C=US/O=UNIV/L=COMP/CN=John Doe/Email=john.doe@comp.univ.edu"
globus

In the file /opt/globus-mds/share/certificates/ca-signing-policy.conf, both Globus and the UNIV CA appear.

What could the problem be?

The failure is happening at 'bind' time; the check on gridmap occurs at the backend, after the bind goes through.

Usually GIIS servers are started as user globus and clients are users. The gridmap file should include the user's DN and their local account name. The gridmap should contain entries for users only. No entry for user globus is needed.

The globus account does not need to do a grid-proxy-init. In fact, make sure that there isn't an old proxy in /tmp that belongs to globus.

Regular user accounts need to have a valid proxy, which can be obtained using grid-proxy-init.

To check if a proxy is still valid, use grid-proxy-info. Make sure that the user's X509_USER_PROXY is pointing to a valid proxy.

If you are testing with ldapsearch, you need to supply the "-Y GSSAPI" parameter to force it to use GSI-GSSAPI.

If the server certificates are owned by root, then the server must be started as root. If the server will be started as globus, then the server certificates must be owned by globus.

Q: Do I need to run grid-cert-request on the same machine as MDS 2.1?

No. The syntax for grid-cert-request is:

grid-cert-request -cn ldap/<FQDN> 
                  -cert servercert.pem -key serverkey.pem
                  -req serverkey.pem
                  -nopw -dir certdir

This can be executed anywhere, on any machine. The -dir can be local to that machine, or on an accessible remote machine. Once received, the certificate can be moved to a new location. The FQDN must be the fully qualified domain name of the machine that MDS 2.1 server will be running on. The certificate authority does not require that the certificate request for machine A must come from machine A.


Q: I downloaded the Globus Toolkit 2.0 release and installed MDS.  All of the installation was successful.

I applied the ldap server certification, and I put servercert.pem and serverkey.pem in GLOBUS_LOCATION/etc.

Then I started MDS with the SXXgris start command.

I could do anonymous (anonymous flag set; without SASL) queries, as follows:

grid-info-search -x -b "mds-vo-name=local, o=grid"
grid-info-search -x -b "mds-vo-name=site, o=grid"

But I could not do security-enabled (with SASL) queries, as follows:

% grid-info-search -b "mds-vo-name=local, o=grid" ldap_sasl_interactive_bind_s: No such attribute

Usually if anonymous queries work but authenticated queries do not, it means the server is up and running.

The problem could be that the wrong server port is being used, i.e., the port is not set up for authentication, or that there are no certificates in the certificate directory.

First, make sure the client has a valid proxy to start with, and second, that the server certificate permission is correct.  The key is probably not world-readable or writable.  You can look into ~globus/.globus.  There are several sets of server certificates that have the right permission to run the server as 'globus'.

If all seems to be correct, find ldapsearch and make calls like:

ldapsearch -x  -s base -h their-host -p their-port -b ""
supportedsaslmechanisms

on the server to see if the mechanism is correct.

Sometimes, it might be because SASL_PATH is not set properly, so client and server cannot find the SASL plug-ins.  If -d 255 is put on the ldapsearch call, it will give a lot more debugging information and can eliminate some other missteps.

Also there is an FAQ page on Globus security you might want to check here.

Q: I installed the Globus Toolkit, and globus-setup-test works.  I am able to submit jobs both to the local machine and our other test grid machine.  But I can't seem to gather any information about available resources.  Nothing in the Installation Instructions says I have to do anything to set up MDS or slapd, but when I run grid-info-search, I get the following (on both machines):

$ grid-info-search '(objectclass=3DGlobusComputeResource)'
ldap_bind: Can't contact LDAP server

If I get more explicit:

$ ldapsearch -p 2135 '(objectclass=3D*)'
ldap_search: No such object

$ ldapsearch -p 2135 -v '(objectclass=3D*)'
ldap_init( <default>, 2135 )
filter pattern: (objectclass=3D*)
returning: ALL
filter is: ((objectclass=3D*))
ldap_search: No such object
0 matches

$ ldapsearch -p 2135 -v -h host
'(objectclass=3DGlobusComputeResource)'
ldap_init( host, 2135 )
filter pattern: (objectclass=3DGlobusComputeResource)
returning: ALL
filter is: ((objectclass=3DGlobusComputeResource))
ldap_search: No such object
0 matches
With ldapsearch you will have to specify a "-b basedn" option, for which grid-info-search supplies a reasonable default.

Q: What are the OID namespaces and schemas for MDS 2.1?

Refer to the MDS Schemas page for an index of schema definitions and descriptions of the schema object classes and attribute types.

Q: Why does no CPU information appear in my GRIS running on Solaris?

The Solaris CPU information provider uses SysInfo, a 3rd party product. For further details of SysInfo, please see http://www.MagniComp.com/sysinfo

The sysinfo executable should be in the path when MDS is installed.

Q: The grid-info-search (or ldapsearch) command is not returning all of the data objects I am expecting. I get the message:

Size limit exceeded (4)

How can I get all the results I expect from the command line query?

There are three different sizelimit parameters involved here. All three of them have defaults, and all three of them affect the number of LDIF data objects returned from a query. These are:

  • The sizelimit option on the ldapsearch command (to which grid-info-search is a wrapper).

  • The sizelimit option in the grid-info-slapd.conf configuration file, which controls the number of objects returned by the slapd server to the client.

  • The sizelimit option for each of the information provider programs in the grid-info-resource-ldif.conf configuration file, which controls the number of objects returned by each provider to the slapd server.

Depending on your environment, you or your system administrator will need to increase one or more of these sizelimit values above their defaults in order to get the number of data objects you are expecting.

Q: I’ve made configuration changes to my MDS setup, but they do not take effect when I start MDS.

You or someone else may have a slapd server from a previous startup of MDS already running on the system, preventing a new slapd from starting. For example, you and another user may both be trying to run slapd servers on the same port. Or there may be a slapd running from a previous version or installation of MDS.

This situation may also cause the slapd server to not start at all when you enter the SXXgris start command to invoke MDS. However, there may be other reasons for the slapd server not starting, such as not setting or sourcing your environment, not having the right certificates, and so forth. Refer to the MDS 2.1 User’s Guide for more information on those topics.

Check your environment for the slapd servers that are currently running. To see which slapd servers are currently running on Linux, enter the following command:

  % ps uawx | grep slapd

From the output of this command, you can see if any old or conflicting slapd servers are running, and you can remove them as appropriate with the kill command.

Note that the SXXgris stop command may not kill the slapd instance you had intended. Use the kill command instead. SXXgris stop is appropriate for when you want to stop MDS, make a configuration change, and restart MDS via SXXgris start, assuming there are no conflicting slapd servers running at that point in time.

Q: How do I view MDS data via a web page?

There are a number of initiatives to expose LDAP data via html/http. Here are two examples:

http://ldapweb.sourceforge.net/

This is an LDAP web interface developed using Apache, PHP, and SSL tools. It can be used to manipulate Microsoft's Active Directory. It provides search, add, delete, and modify capabilities, as well as schema recognition.

http://freshmeat.net/projects/ldapwebxplorer/?topic_id=90

This is a PHP-based LDAP web interface. It provides browse, edit, delete, search, and authentication capabilities. It has some multilingual capabilities, a friendly interface, and an extendable configuration.

Q: I am currently setting up a hierarchical GIIS. Everything works fine except registration from one GIIS to another GIIS. Could some character in the mds-vo-name be the cause of the problem (seems like the syntax required by the schema should not accept '_' - underscores)?
The attribute type of "mds-vo-name" is "printable string," which doesn't allow '_' (underscore).

Q: I’m trying to solve a problem by looking at the logfile grid-info-system.log, but it barely says anything. How can I raise the log level to see what is happening there?

In the SXXgris file in $GLOBUS_LOCATION/sbin, there is a call to grid-info-soft-register, with a parameter "-d 0". You can change this to, for example, “-d 255” to get lots of debugging information.

Edit the grid-info-soft-register file (also in $GLOBUS_LOCATION/sbin) to remove all of the > /dev/null redirections. In this file, change:

  ${MASTER_DAEMON_PATH} "$@" > /dev/null 2> /dev/null &

to:

  ${MASTER_DAEMON_PATH} "$@" &

This should give you a lot of output to both stdout and stderr.

Q: I’m trying to set up Globus Toolkit 2.0. Everything seems to be working, except I can only do anonymous MDS searches. If I enter grid-info-search without the “-x” option, I get this output:

SASL/GSI-GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error

I think I have everything set up correctly: the server.cert and server.key files are in $GLOBUS_LOCATION/etc, the grid-mapfile is in /etc/grid-security, the usercert.pem and userkey.pem are in $HOME/.globus, and all the environment variables that I can see are pointing to the right locations (including SASL_PATH). Remote jobs run fine, as do anonymous MDS queries.

Assuming everything else is in fact set up properly, the problem may have to do with how the host names of the machines are being reported. When a host name is looked up on a machine without that host name in its /etc/hosts file, it is looked up through DNS and returns the correct result. If the machine does have a host name in its /etc/hosts file but the host name is not in fully qualified format, or is in that format but does not appear first on the line referencing it, it fails to resolve correctly and the Globus Toolkit is not able to authenticate its certificate.

For example, a hosts file appearing like this will not allow authenticated access because the fully qualified name appears second on each line:

122.0.0.1 host01 host01.univ.edu localhost
125.213.49.87 host01 host01.univ.edu

A hosts file appearing like this will allow authenticated access because the fully qualified name appears first on each line:

122.0.0.1 host01.univ.edu host01 localhost
125.213.49.87 host01.univ.edu host01

If correcting the hostnames in /etc/hosts does not solve your authentication problem, refer to the other FAQs on this issue:

Bind error on grid-info-search command
Can do anonymous but not security-enabled queries