I use password authentication to login with an AD account into a windows
terminal services platform. All windows platforms are 2003 R2, then ssh using
gssapi to get to OpenBSD - no password required, or the same to Solaris 10, Red
Hat v4 platforms. I use a modified version of putty from Quest that supports
gssapi on Windows, sshd_config has gssapi enabled. I can login using cygwin ssh
or locally with the AD account/password to OpenBSD. The real aim in this case is
to use a single sign-on. I can also use smart card authentication to the
terminal server, and the single sign-on to any Linux/Unix platform and OpenBSD.

I am using OpenBSD v4.6 stable, running samba v3.4.3 ads favour see mail lists,
ldap-client, ldap-server, p5-ldap from ports, portmap, ypldap, ypbind, plus
other ports. Note I use a modified ypldap - that allows empty groups, this is
for another system using smbldap-tools the aim to automatically add samba users
in ldap.

ypldap uses an extra login class kauth defined in login.conf with auth=krb5. An
entry in ypldap.conf fixed attribute class "kauth" is used.

Red Hat and Solaris are using Quest's Vintela, this extends the AD schema in a
manner ypldap does not support (or I haven't found a way to make this work so
far, I need to do some sub queries for memberships), instead I extract using a
perl script creating a ldif file which creates the entries in local ldap server
for users/groups using the nis schema. I have around 140 users and 30 groups
from AD in the local ldap, the perl script also filters out any users that
haven't been assigned a uid, or groups with no gid and users with a uid's below
a value, and disabled accounts. the perl script uses Net::LDAP from the p5-ldap
port.

This also works with samba, the terminal server can get to samba shares on the
OpenBSD, using the group/users setup in ldap and authenticating with AD.

To get multiple groups for users besides a +, as the last line the group file,
the group file must contain an exclusion see getgrouplist man page, or you need
to create /etc/netid for the user to group mappings. ypldap doesn't support
netid.byname currently, sudo doesn't work because of this.

The only difference is the ypldap.conf refers to the local ldap in my case
populated with the AD accounts/groups, rather than using ypldap directly against
the active directory ldap.

getent passwd or group will return both local and those accounts/groups in ldap.

The yp_first is reported by ypbind, your initial e-mail suggests ypldap hasn't
completed the first stages, you should see something like this

# ypldap -dv
startup [debug mode]
configuration starting
applying configuration
connecting to directories
starting directory update
updates are over, cleaning up trees now
flattening trees
pushing line: aalle01:*:5020671:5046:kauth:0:0::/home/adusers/aalle01
        :/bin/bash
pushing line: aarno01:*:5972151:5002:kauth:0:0::/home/adusers/aarno
         01:/bin/sh
pushing line: acham01:*:5617157:5002:kauth:0:0::/home/adusers/acham
         03:/bin/sh
pushing line: acham02:*:5020098:5046:kauth:0:0::/home/adusers/ach
       am02:/bin/bash
pushing line: achil01:*:50042186:5001:kauth:0:0::/home/adusers/achil01
            :/bin/sh
.....
pushing line: ncwadmins:*:5024:dmell01,npres01
pushing line: ncwops:*:5043:dmell01,npres01
pushing line: nfmadmins:*:5032:dmell01,npres01
pushing line: nfmops:*:5031:dmell01,npres01
pushing line: nmnadmins:*:5028:dmell01,npres01
.....

I think until ypldap reaches this point it's not listening, and ypbind can't
connect.

You could try ypldap.conf with a filter for a small set of users / groups. This
will tell you if you exceeded a limit or there something wrong in the 
ypldap.conf.


Regards

Nigel Taylor


Joakim Dellrud wrote:
> Okay, I have understood that there is some difference between a solution and
> another. But what I need to do is to pull a user with the unix attributes in
> a 2k3 ad server to a bsd machine. It is already working seamless in a centos
> enviroment. But there is the nsswitch and pam. My problem is that I have to
> use the smallest amount possible of space and packages for this to work. For
> the record I already have the UNIX SFU installed (thought I did mention
> that).
> 
> I had the impression that ypldap.conf is equal to the ldap.conf I use in the
> centos env. Is that not the case? Is ypldap not used to bind against an ad
> with a user and pull info that then are used to auth against?
> 
> ======
> 
> I don't know if I need to clarify what I want to do but I will anyway:
> The existing Active Directory (with SFU) are going to host two types of
> users one USER with one password and another USER.root with a different
> password. Then when I ssh against one server I want to use my USER and when
> inside I use kinit USER.root to gain a "root" ticket (afterwards I use ksu
> to elevate the USER to the local root account). In Centos I've managed to
> make this work through editing of /etc/krb5.conf, /etc/openldap/ldap.conf,
> /etc/ldap.conf, /etc/nsswitch.conf and /etc/pam.d/system-auth. The same
> applies to all the debian based systems. What I am aiming for is to have the
> possiblity in BSD just to ssh with my USER and then use su(?) to change to
> my USER.root. The trouble I'm having is that ypldap.conf does not give the
> functionality I want and login_ldap seems to do nothing. I know the error is
> with me so what have I done wrong. The kerberos is working against the AD
> and I can get tickets but to be able to have all users in one place I need
> the AD to LDAP connection and this is where I fail.
> 
> Here is a getent passwd from a centos host (it is still in testing :P)
> 
>   unixUser:*:10001:70000:TEST:/home/bananas:/bin/bash
>   UnixUser.root:*:10005:70000:TEST:/home/bananas:/bin/false
>   test:*:10006:70000:test:/home/bananas:/bin/bash
>   root:x:0:0:root:/root:/bin/bash
> 
> I want the same to be the case on the bsd but I'm stuck at the error:
> "yp_first: clnt_call: RPC : Timed out". My first thought was that there was
> something in the DNS/name space that where giving me trouble but even when I
> change to the IP of the AD it wont work. I've checked and the kerberos
> connection never fails.
> 
> // Regards Spixx

Reply via email to