What is the difference between VB6 and VB.NET

There are quite a few differences in VB6 and VB.NET. We will highlight some of these here in points:

• The greatest change in VB6 and VB.NET is of runtime environment. VB6 used the VB-Runtime while VB.NET uses the .Net Common Language Runtime (.Net CLR). The CLR is much better designed and implemented than VB-Runtime. The CLR uses better code translation through Just in Time compiler while VB-Runtime interprets the code. The CLR Garbage Collector is also more efficient than VB6 one as it may detect cyclic references too.

• VB6 was interpreter based language while VB.NET is a compiled language

• VB6 was not a type-safe language while VB.NET is a type safe language. There is no variant type in VB.NET and no magical type conversions happen in VB.NET

• VB6 used ‘On Error Goto’ syntax to handle exceptions at runtime. VB.NET uses the Try…Catch…Finally syntax to handle exceptions at runtime.

• A lot of code (like user interface code) in VB6 was hidden from developer. In VB.NET no code is hidden from developer and you can access and control each part of your application

• VB.NET has much enhanced object oriented support than VB6

• VB6 does not allow developing the multithreaded applications. In VB.NET you can create multithreaded applications.

• VB6 was only considered good for desktop windows application. In VB.NET you can also develop web applications, distributed applications, create .NET windows and web controls and components, write windows and web services.

• In VB.NET, you can also use reflections to read the meta-data of types and using reflection emit you can also generate code to define and invoke types at runtime.

• VB.NET uses .NET framework class library along with specialized VB library (System.VisualBasic) as a standard library. As a result, the standard library for VB.NET is much enhanced and useful compared to VB6 standard library

• VB.NET is platform independent because of .Net framework. Programs written in VB.NET can run on any platform where .Net framework is present. The platform include both hardware and software (operating system) platforms.

• VB.NET also supports language interoperability with various .NET compliant languages. This means that you can use and enhance the code written in other .NET compliant languages. Similarly the code written in VB.NET can also be used and enhanced by other .NET compliant languages. Although VB6 also provided this functionality through COM but it was limited and difficult to use and manage. VB.Net makes it easier because of the presence of Intermediate Language (IL) and Common Language Specification (CLS) of the .NET architecture.

• VB6 uses COM (Component Object Model) as component architecture. VB.NET uses assemblies as its component architecture. The Assemblies architecture has removed a lot of problems with COM including DLL-Hell and versioning problem.

• Components created in VB6 (COM) need to make and update registry entries. VB.NET does not require any registry entry making the deployment easier

• VB6 used ASP to build web applications. VB.NET uses ASP.NET to build web applications.

• VB6 used ADODB and record-sets to implement data access applications. VB.NET uses ADO.NET and datasets to build data access applications. The ADO.NET also supports the disconnected data access.

Integrating LDAP and Kerberos: Part One (Kerberos)

Original Post by Juliet Kemp...

Click here to see Profile:::

LDAP and Kerberos are widely used, separately, yet integrating them seems less popular. This is a shame, as they fit together very well — in particular, you should avoid using LDAP for authentication, for which it is not well designed. Security is increasingly important for all sites, and Kerberos is a massive security increase over LDAP authentication.

What is LDAP?

LDAP stands for Lightweight Directory Access Protocol — it is not itself either hardware or software, but a protocol to define how a client and server interact with each other. An LDAP directory is used to describe a directory whose server corresponds to this protocol.

LDAP works by the client asking the server for particular information, the server runs the appropriate search (e.g. to find the entry for a given uid), and returns that information to the client. An entry is a structure which holds information about an object, and entries are arranged in a tree structure.

Schemas are used to prescribe the syntax and structure for particular types of object and particular object attributes. Plenty of standard schemas are available, and you can also create your own schemas or add to existing ones, in order to meet the needs of your site.

LDAP can run either (using SSL, on port 636 as ldaps:///) or over a unsecured connection (on port 389 as ldap:///). The next part of this piece will explain how to set up a secure LDAP server, using OpenLDAP.

What is Kerberos?

Kerberos only handles authentication, of machines or of users. When a user logs in to their machine, they request a Ticket-Granting Ticket (TGT) from the Key Distribution Center (your main Kerberos server, or a slave server). The KDC finds the user in its database, then sends back a TGT encrypted using their key. That TGT is decrypted at the other end with the user's password. Therefore the password isn't sent over the network, increasing security.

After that, any kerberized service uses this TGT to ask for a service-specific ticket: the user doesn't need to enter their password again until the TGT expires (usually 10 hours), or is deleted. So, for example, if your entire system is Kerberos authenticated, you can log on once and then ssh to any system without having to re-authenticate.

The process works similarly for services or machines — except that a locally stored key is used instead of a password.

If you want more information, there's an excellent and very readable explanation of how Kerberos works on the MIT Web site.

The rest of this article will deal with setting up Kerberos (the MIT version) — it's easier (in my experience) to set up Kerberos first, then LDAP, than the other way around.

Kerberos server setup

Let's start with installation and configuration. Kerberos should be available from any distribution — or, of course, you can compile from source. The Debian/Ubuntu packages needed are krb5-kdc, krb5-admin-server, libkrb5-dev, krb5-config, krb5-user, krb5-clients, and libkadm55.

During the installation of the packages you'll be asked for the hostname of your server. This should be the fully qualified domain name (FQDN) of your server — e.g. kerberos.example.com.

Most of the configuration is done in /etc/krb5.conf. Edit this to look as follows:

[libdefaults]
default_realm    EXAMPLE.COM
[realms]
 EXAMPLE.COM = {
       kdc = kerberos.example.com
       admin_server = kerberos.example.com
       default_domain = example.com
   }
[domain_realm]
   .example.com = EXAMPLE.COM
   example.com = EXAMPLE.COM
[login]
   krb4_convert = false
[logging]
   kdc = FILE:/var/log/kerberos/krb5kdc.log
   admin_server = FILE:/var/log/kerberos/kadmin.log
   default = FILE:/var/log/kerberos/krb5lib.log

Your realm should match your local domain, as illustrated above. The [logging] section is optional, but simplifies debugging.

If you want to set up a slave kerberos server as well as the master, you can have multiple KDC lines. The KDC, as mentioned above, does the giving out of TGTs, and you can have as many as you like. However, you only have a single admin server, which acts as the master KDC.

Start the kerberos admin server and the KDC (/etc/init.d/krb5-admin-server start; /etc/init.d/krb5-kdc start). It's normal for it to take some time to start the admin server — so be patient.

Setting up the database

Now you'll need to create the initial database and populate it with your inital admin user(s).

Initially, you use kadmin.local for this — this only ever runs locally on the master server, and does not use Kerberos to authenticate to that server. So, before you have a Kerberos database, it's the only way to talk to the server! After you have your admin user set up, you should use kadmin instead.

The commands to issue from the command line are:

    kdb5_util create -s 
   kadmin.local -q "ktadd -k /etc/krb5kdc/kadm5.keytab kadmin/admin"    
   kadmin.local -q "ktadd -k /etc/krb5kdc/kadm5.keytab kadmin/changepw" 
   kadmin.local -q "addprinc krbadm@EXAMPLE.COM"  
   kadmin.local -q "addprinc ldapadm@EXAMPLE.COM" 

The first command creates your database, and the next two are needed to enable admin changes to happen. The final two commands create a Kerberos admin principle (krbadm) and an LDAP admin principal (ldapadm) — you'll be asked to provide a password.

Obviously, your choice of usernames in the last two lines is up to you! Or you can have a single admin user. Some sites prefer to create admin users that look like krbadm/admin@EXAMPLE.COM to make it clear which users have admin privileges.

You also need to edit the ACL (access control), in the file /etc/krb5kdc/kadm5.acl. A very basic example corresponding to the above setup is as follows:

krbadm@EXAMPLE.COM              *
*/admin@EXAMPLE.COM             *
*/*@EXAMPLE.COM                 i
*@EXAMPLE.COM                   i

This gives all access to the Kerberos admin user, and to any /admin user, and read-only access to all principals in the domain (note that */* and * are both required — just as user/admin@EXAMPLE.COM and user@EXAMPLE.COM are both different).

Edit /etc/krb5kdc/kdc.conf to set EXAMPLE.COM as the realm, and ensure that the database, keytab, and ACL locations match what you set in the database creation above. Note that the admin_keytab location must be specified as FILE:/etc/krb5kc/kadm5.keytab, not just as the bare filename.

Restart krb5-kdc and krb5-admin-server for the changes to take effect. From now on, you use kadmin -p krbadm to make changes.

Check that all is working by typing kinit krbadm — you should be challenged for the password. Then type klist and you will see that you have an authorized principal krbadm.

Kerberos client setup

The Debian packages needed are: krb5-user (for klist and kinit), ntpdate (the time on server and client must match), and libsasl2-gssapi-mit. Edit /etc/krb5.conf to make sure that the following entries are correctly set:

[libdefaults]
 default_realm = EXAMPLE.COM
[realms]
 EXAMPLE.COM = {
       kdc = kerberos.example.com
       admin_server = kerberos.example.com
   }
[domain_realm]
 example.com = EXAMPLE.COM
 .example.com = EXAMPLE.COM

This may already have been done by the Debian package configuration, if you answered the questions correctly.

SSH and logon

You next need to set up both server and clients to use Kerberos for logon and for SSH logon. Debian users will need to install libpam-krb5, openssh-server, libsasl2-dev, libsasl2-gssapi-mit, and libsasl2-modules. The same packages should be available for Ubuntu and other distros, but (in some cases) with different names.

Edit /etc/pam.d/common-auth and /etc/pam.d/common-session to use pam_krb5.so.1, as follows:

# /etc/pam.d/common-auth
auth    sufficient  pam_krb5.so use_first_pass ignore_root forwardable
auth    required    pam_unix.so nullok_secure try_first_pass

# /etc/pam.d/common-session
session         sufficient      pam_unix.so
session         sufficient      pam_krb5.so ignore_root

The sufficient line enables local login (e.g. by root) if necessary. At least one line in common-auth must be required, or you will be able to log in without a password, which probably isn't desirable.

The use_first_pass and try_first_pass options mean that you get asked for your password only once, whichever module is used. ignore_root means that the kerberos module is not used for root login — this is more secure.

For ssh, edit /etc/ssh/sshd_config to set the various Kerberos options as follows:

KerberosAuthentication yes
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes

UsePAM yes
AllowTcpForwarding yes

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
GssapiKeyExchange yes

Then edit /etc/ssh/ssh_config to set both GSSAPIAuthentication and GSSAPIDelegateCredentials to Yes.

You need to add the server host to the keytab in order to enable ssh to transfer the Kerberos credentials. From the client, run kadmin -p krbadm (authenticating you as the admin user) and execute these commands:

addprinc -randkey host/client.example.com
ktadd host/client.example.com

The -randkey option generates a random key rather than asking for a password — this is obviously preferable for a non-person entity.

Testing

Now it's time to ensure that everything is in working order. Create a test user via kadmin:

addprinc test@EXAMPLE.COM

Test the setup by first logging on with console, then with graphical logon, and then via ssh. Once logged on to one kerberized machine, you should be able to ssh to another kerberized machine without typing your password again.

Troubleshooting

Things to check if it doesn't work smoothly:

• Check the time on the KDC and the client machine — they must be the same. (There's a tolerance of 5 minutes by default).

• Check that you can ping the KDC and that there aren't any other network problems.

• Check that the host key has the correct number, by executing the following on the client:

  sudo klist -k /etc/krb5.keytab
  kinit krbadm
  kvno host/client.example.com
  

  If they are not the same, you need to start up kadmin, remove the client principal from the keytab (ktrem), delete it (delprinc), then recreate and re-add it.

Now you should be able to use Kerberos for authentication. The next part of this article will tackle setting up your LDAP server.

Juliet Kemp has been playing with Linux systems for around 6 years now, after discovering that it was an excellent way to avoid Finals revision. She is currently sysadmin for the Astrophysics group at Imperial College, in London (UK), and is responsible for wrangling a Linux+Solaris network and its users.

Integrating LDAP and Kerberos(Part 2)

OpenSSL

OpenSSL enables you to run a secure LDAP server (over ldaps:/// on port 636). The relevant Debian packages are libssl-dev, openssl, ca-certificates, and libssl0.9.8.

To generate a self-signed certificate:

1. First generate a certificate authority:

cd /etc/ssl
/usr/lib/ssl/misc/CA.sh -newca

The CN asked for here must be the FQDN of the LDAP server. Do not use the "challenge password" attribute, but do set the PEM passphrase (and remember it!).
2. Create the certificate:
openssl req -new -x509 -nodes -out newreq.pem -keyout newreq.pem -days 365

The -nodes switch is important in order to create an unencrypted certificate, so that it will work with LDAP. Again, when asked for the CN, it needs to be the FQDN (fully qualified domain name) of your server, e.g. ldapserver.example.com.
3. Sign the certificate:
/usr/lib/ssl/misc/CA.sh -signcert

Again, do not use a challenge password. The new certificate will be in newcert.pem. (Note: this script looks for the file newreq.pem and signs that; if you have used another file in the certificate creation you will need to rename or copy it.)

If you want Verisign or another Certificate Authority to sign your certificate, the process is easier — you only need step 2, and should leave out the -x509 switch. Check the instructions from your CA as to what you should do with the certificate request.

Once LDAP is installed, you will move the certificate files to the LDAP directory as explained below.

LDAP server setup

The Debian packages you need are libldap2, slapd, ldap-utils, libdb3-dev, and libdb3 (these last two provide the BerkeleyDB database backend). Set the admin password when asked during dpkg-configure.

To use SASL correctly, you need to put the certificates generated above in the correct places:

mv /etc/ssl/newcert.pem /etc/ldap/servercrt.pem
mv /etc/ssl/newreq.pem /etc/ldap/serverkey.pem
mv /etc/ssl/demoCA/cacert.pem /etc/ldap/cacert.pem
chmod go-r /etc/ldap/serverkey.pem
chown openldap /etc/ldap/serverkey.pem
chmod a+r /etc/ldap/servercrt.pem

Edit /etc/default/slapd to include these lines:

SLAPD_SERVICES="ldaps:///"
SLAPD_OPTIONS="4"

LDAP configuration

To use LDAP with Kerberos, you need to get a copy of krb5-kdc.schema and put it in /etc/ldap/schema/.

Edit /etc/ldap/slapd.conf:

include /etc/ldap/schema/krb5-kdc.schema
include /etc/ldap/schema/openldap.schema

# ... other things that can stay as provided ...

TLSCACertificateFile /etc/ldap/cacert.pem
TLSCertificateFile /etc/ldap/servercrt.pem
TLSCertificateKeyFile /etc/ldap/serverkey.pem

# ... other things that can stay as provided ...

# this section rewrites principals as needed for Kerberos authentication
authz-policy from
authz-regexp
uid=(.*),cn=example.com,cn=GSSAPI,cn=auth
uid=$1,ou=people,dc=example,dc=com
sasl-realm EXAMPLE.COM
sasl-host ldapserver.example.com

include /etc/ldap/slapd.access

# ... rest of file ...


Edit /etc/ldap/slapd.access to set your permissions. I've provided a basic example; you can complicate it about as much as you want!

# Everyone can read everything
access to dn.base="" by * read

# The admin dn has full write access
access to *
by dn="uid=ldapadm,ou=people,dc=example,dc=com" write
by * read

# Temporary lines to allow initial setup
rootdn "cn=admin,dc=example,dc=com"
rootpw secret

Note that you must not have comment lines between the 'access' and 'by' lines in this file, or it won't work.

The ACLs should also go before the database backend definitions (so they apply globally) — this means that the include slapd.access line in /etc/ldap/slapd.conf must occur before the database backend definitions.

Put this line in /etc/ldap/ldap.conf:

TLS_REQCERT allow

This allows clients to request the TLS server certificate from the server, thus saving you having to copy it everywhere.

If you need it, there is more config information for TLS/SSL in the OpenLDAP FAQ.

To separate out the slapd logs from the general systems logging, edit /etc/syslog.conf and add the following line:

local4.* /var/log/slapd.log

LDAP and Kerberos

Add the LDAP server to kerberos, by running kadmin -p krbadm from the LDAP host, and executing these commands:

addprinc -randkey ldap/server.example.com
ktadd -k /etc/ldap/ldap.keytab ldap/server.example.com

You should extract the server key to a keytab other than the system one at /etc/krb5.keytab (this is what the -k flag does), since the LDAP keytab must be owned by the LDAP user. Change the file ownership appropriately.

You also need to ensure that slapd is looking at this keytab. Add the following line to /etc/default/slapd:

export KRB5_KTNAME=/etc/ldap/ldap.keytab

Now, restart slapd.

If there are problems with startup, change the log level in /etc/ldap/slapd.conf to 16383 to get verbose logging in the log file. Change it back before you go into production, as verbose logging makes the server very slow.

Setting up the database

To set up the database, you first use the authentication in the rootdn and rootpw directives, to add the root entry, the People group, and an admin user (e.g. ldapadm — you should have added this user when you set up Kerberos).

For this you need to create a "setup" LDIF file (setup.ldif). You need to choose your base domain, which will depend on your organization. It's a good idea to use a base domain that is related to your Kerberos domain and also to your IP domain. Here we use dc=example,dc=com.

# setup.ldif
dn: dc=example,dc=com
objectclass: organization
objectclass: dcObject
objectclass: top
o: Example Company
dc: example
description: root entry

dn: ou=people,dc=example,dc=com
objectclass: organizationalUnit
ou: people
description: Users

dn: uid=ldapadm,ou=people,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
cn: LDAP admin account
uid: ldapadm
uidNumber: 1002
gidNumber: 100
homeDirectory: /etc/ldap
loginShell: /bin/false

Note that the LDAP user cannot log in directly.

To add this, use ldapadd:

ldapadd -x -D "cn=admin,dc=ph,dc=ic,dc=ac,dc=uk" -W -f setup.ldif

-W is the option which causes the password to be demanded, -x uses an anonymous bind.

After this, edit /etc/ldap/slapd.conf again to remove the rootdn and rootpw entries. From now on you can authenticate as the ldapadm user to add or modify entries. Restart slapd.

Testing!

Before you fully populate the database, it's time to check that it works. Try the below, first from the server. Once that's working, set up a client (see below) and try it from there.

* ldapsearch -x -H ldaps://server.example.com (The -x option gives a simple bind.)
* ldapsearch -x -H ldaps://server.example.com -ZZ -TLS (This test TLS startup.)
* kinit username; ldapsearch -H ldaps://server.example.com (This to test kerberos auth.)

Troubleshooting notes:

*

Add -d 16383 to the ldapsearch line to enable copious debugging output.
*

Check the permissions on /etc/ldap/cacert.pem — it needs to be world-readable.
*

Check /etc/hosts if the hostname is resolving incorrectly (this will show up in the debugging output — your client needs to be trying server.example.com, not just server).
*

If you get the error "Key version for principal in keytable is incorrect", there is a mismatch between the kerberos keytab and the master server. On the LDAP host, run kadmin -p krbadm and execute the following:

ktrem ldap/server.example.com
delprinc ldap/server.example.com
addprinc -randkey ldap/server.example.com
ktadd ldap/server.example.com

*

If you get the error "GSSAPI Error: Miscellaneous failure (Permission denied)", check that the LDAP keytab is readable by the ldap user, and that slapd is looking at the correct keytab. You can test this quickly by also adding ldap/server.example.com to the system keytab at /etc/krb5.keytab and making that world-readable. If that starts things working then your keytab may be the problem. Remember to change it back to root-only afterwards!
*

Note that having high levels of debugging will slow things down dramatically — turn debugging off or down once things are working. If you are not getting errors, but ldapsearch appears to be hanging, try reducing the log levels in /etc/ldap/slapd.conf and restarting slapd.

Populating the LDAP database

You have many options to populate the database. If you already have users, you'll want to migrate your data — PADL provide tools (the migrationtools package on Debian). This works fine for regular Unix setup (/etc/passwd, /etc/shadow, /etc/groups), and also for NIS. With some adjustment it will also work for NIS+.

You will, however, need to migrate your passwords to Kerberos by hand. This may be a good time to make everyone change their passwords.

To import an existing database: stop slapd, run slapadd -l existing_database.ldif, and restart slapd (where existing_database.ldif is an LDIF dump of an existing database).

You may need to empty the database first: do this by stopping slapd and removing the contents of the database directory — this is specified in /etc/ldap/slapd.conf by the directory directive.

Remove the rootdn and rootpw entries from slapd.conf, then start and stop slapd again before importing the database. If you have startup problems, check that the database directory is owned by the LDAP user (openldap on Debian).

Finally, you need to make sure that you have no password references in your user database — Kerberos will be handling passwords for you, and the easiest way to make this happen is simply to remove all password references from LDAP.

Run kinit ldapadm, and then use ldapsearch to get the attributes for any user: for example, to search for a user named "jkemp" you'd use ldapsearch ("uid=jkemp"). Look for any password attributes. Then for any individual user, you can create the following ldapmodify file:

dn: cn=username,ou=People,dc=example,dc=com
changetype: modify
delete: userPassword

Replace userPassword as appropriate. Then run ldapmodify -f modifyfile. You can put multiple users in the same file: use the same syntax as above, but separate each instance with a blank line.

Alternatively you can of course edit any data migration tool so as not to take the password data.

Client setup

You'll need the following packages: ldap_utils, libnss-ldap, autofs-ldap (if you use automount), and nscd.

After installing the packages, edit /etc/nsswitch.conf as follows:

passwd: compat files ldap
shadow: compat files ldap
group: compat files ldap

hosts: files dns

services: db files ldap [NOTFOUND=return]
networks: db files ldap [NOTFOUND=return]
protocols: db files ldap [NOTFOUND=return]
rpc: db files ldap [NOTFOUND=return]
ethers: db files ldap [NOTFOUND=return]

automount: files

It's important that compat and files entries appear before ldap for passwd, shadow, and group — otherwise if your LDAP server fails (or the client connection to it does) you won't be able to log in at all. You can use ldap for hosts as well if you prefer.

Edit /etc/libnss-ldap.conf so that the only lines uncommented are:

base dc=example,dc=com
uri ldaps://ldapserver.example.com
ldap_version 3

Edit /etc/ldap/ldap.conf as follows — some of these may be auto-filled from installation questions.

BASE dc=example,dc=com
URI ldaps://ldapserver.example.com
TLS_REQCERT allow

The last line enables the client to request the server's certificate, and saves you installing it on every client.

To set up automount to read from LDAP, you need the autofs-ldap package. Note that you want to use files in /etc/nsswitch.conf (as above) rather than ldap — this seems more reliable. Edit /etc/auto.master as follows:

/home ldap:nisMapName=auto_home,dc=example,dc=com

Customize as appropriate for your setup. Here the dn uses nisMapName, which is for automounts which were converted from NIS+. You can also use automountMapName.

To test your setup, try the following on the client:

ldapsearch -d 1 -x

You should see the TLS info at the top and bottom of the debug output (generated with the -d 1 flag). If you have any problems, try specifying the server with -H ldaps://ldapserver.example.com — if this works, check the values in /etc/ldap/ldap.conf.

Finally, test that Kerberos auth is working by typing kinit, then ldapsearch (i.e. without the -x simple bind option).

Now you're there!

Using LDAP

The basic LDAP commands are ldapadd, ldapmodify, and ldapdelete. Execute kinit ldapadm before any of these, to authenticate yourself.

* ldapadd:
o

ldapadd -f newuser.ldif
o

newuser.ldif could look like this:

dn: uid=username,ou=People,dc=example,dc=com
uid: username
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
loginShell: /bin/tcsh
uidNumber: userid
gidNumber: groupid
homeDirectory: /home/username
gecos: Real Name
cn: Real Name

dn: cn=username,nisMapName=auto_home,dc=example,dc=com
objectClass: nisObject
cn: username
nisMapEntry: server:/export/home/username
nisMapName: auto_home

This would create both a user entry, and an entry for the autofs map to set up their home directory. Note the blank line between the two entries.
* ldapsearch:
o ldapsearch "(uid=username)"
* ldapmodify (again you need to authenticate first):
o ldapmodify < modify_file
o

Example of modify_file:

dn: uid=jkemp,ou=People,dc=example,dc=com
changetype: modify
replace: loginShell
loginShell: /bin/bash

This would change the user's login shell to /bin/bash.
o

Another example, which adds a field:

dn: uid=jkemp,ou=People,dc=example,dc=com
changetype: add
add: emailAddress
emailAddress: user@example.com

* ldapdelete:
o

Run ldapdelete "cn=isis,ou=Hosts,dc=example,dc=com" — you need to specify the DN of the entity you wish to delete.
o

You can also use ldapdelete -f file, where file contains a list of DNs, one per line, all of which will be deleted in turn.

Your site should now be happily Kerberized and LDAP-ized. You can set up various other applications to use LDAP as a directory server (e.g. mail clients, to get an address book) and Kerberos for authentication (e.g. your Web server).

Juliet Kemp has been playing with Linux systems for around 6 years now, after discovering that it was an excellent way to avoid Finals revision. She is currently sysadmin for the Astrophysics group at Imperial College, in London (UK), and is responsible for wrangling a Linux+Solaris network and its users.