HostObject/Host_attr checking problem in LDAP Solved

[Brian Fahrlander]

     I've seen a handful of people seeking in Ubuntu, what Redhat seems 
to have worked out in the host-checking of LDAP.  And, I've seen a great 
number of very, very talented people trying to make them understand the 
LDAP babble one learns, when one _completely_ understands LDAP, and a 
lot of threads come to an end that way.

     However...I've just knitted from those threads the answer the 
lonely few of us have been seeking, and can now explain it to those 
searchers properly.  (I'd really like to add this to the Wiki, if we can 
all decide into which one it should go...)

     The secret is in grabbing a schema that isn't packaged with Dapper 
or Feisty so far, called "ldapns.schema". I'm including a copy for those 
searchers to find it. It's from the PADL distro- I don't know the 
historical differences between that and the one we use, yet.

     This file, when put into /etc/ldap/schema/ldapns.schema, and you 
tell SLAPD to use it makes the host-checking possible:

.
.
.
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/inetorgperson.schema
include         /etc/ldap/schema/evolutionperson.schema
include         /etc/ldap/schema/ldapns.schema  <---- Right here.
.
.
.

     Once that's there,and the server has been restarted, it will permit 
you to add "HostObject" to the structure of your People, and to that, 
add the "host" attribute with the various hosts on which they're 
permitted to login.

     Once you've done that with everyone's login, you can start changing 
the workstation's /etc/libnss-ldap.conf files to act upon this change. 
The line "#pam_check_host_attr yes" is uncommented and you should be 
ready to go!

     Theory of operation:

     HostObject is part of "Account", and it's fighting with 
PosixAccount and inetOrgPerson.  What this schema does is to name one 
all by itself, without any complication from either of the other 
schemas, and just let  you tag one onto each real person in your LDAP 
database.

     No, this isn't perfect- the perfect way is to know everything 
possible about LDAP, which vendor/ideology you want to support, and make 
an informed decision.  But this way can allow you to postpone that day 
until you re-org your server.

     Here's the schema:
----------------------------------------------------------------------------
# $Id: ldapns.schema,v 1.3 2003/05/29 12:57:29 lukeh Exp $
# LDAP Name Service Additional Schema
# http://www.iana.org/assignments/gssapi-service-names

#
# Not part of the distribution: this is a workaround!
#

attributetype ( 1.3.6.1.4.1.5322.17.2.1 NAME 'authorizedService'
          DESC 'IANA GSS-API authorized service name'
          EQUALITY caseIgnoreMatch
          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

objectclass ( 1.3.6.1.4.1.5322.17.1.1 NAME 'authorizedServiceObject'
          DESC 'Auxiliary object class for adding authorizedService 
attribute'
          SUP top
          AUXILIARY
          MAY authorizedService )

objectclass ( 1.3.6.1.4.1.5322.17.1.2 NAME 'hostObject'
          DESC 'Auxiliary object class for adding host attribute'
          SUP top
          AUXILIARY
          MAY host )
-----------------------------------------------------------------------------------

     Here's the way it looks in an LDIF:

dn: cn=Brian Fahrlander,ou=People,dc=altavista,dc=local
givenName: Brian
sn: Fahrlander
cn: Brian Fahrlander
uid: brian
uidNumber: 1004
gidNumber: 508
homeDirectory: /home/brianf
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
objectClass: organizationalPerson
objectClass: hostObject   <------------ New structure here
loginShell: /bin/bash
mail: brian at fahrlander.net
o: Fahrlander.net
l: AltaVista Compound
gecos: Brian Fahrlander
shadowLastChange: 13455
userPassword: {CRYPT}7jTbD0LpJEFTE
host: * <------------------------------- a "*" means all hosts

---------------------------------------------------------------------------


     And maybe we on the Ubuntu side can figure out how to make this a 
normal part of the community-supported documentation.  I'm willing to help!
  ------------------------------------------------------------------------
  Brian Fahrländer                 Christian, Conservative, and Technomad
  Evansville, IN                              http://Fahrlander.net/brian
  ICQ: 5119262                         AOL/Yahoo/GoogleTalk: WheelDweller
  ------------------------------------------------------------------------