Owen Greaves wrote:
>
> I should explain a bit more. We are migrating Novell out of our office and
> moving those servers (three of them) to Slackware. These three servers are;
> two file servers and one back-up unit. I had to hire a consultant to come in
> and do it because my three network...experienced people have left and I'm
> trying to hire ONE strong Unix or Linux Admin. This consultant has been
> installing debian without our knowledge after being told we wanted Slackware
> as that is what my current people are familiar with for the most part
> including myself. So they are setting up a Samba box that will have to work
> a number of Windows 2000 Servers (Active Directory). The problem with
> migrating Novell File Servers to Samba is the permissions and authentication
> doesn't come over with the data when moved to the new server.

So, you're replacing NetWare, and you're not keeping the user database
by going for eDirectory on Linux. Instead, you've migrated the users to
Active Directory, but you want Slackware to serve the files using Samba,
and authenticate against AD.

Why not keep NDS/eDirectory? And if you have to get rid of it, why use
Active Directory and not, say, OpenLDAP?

And yes, it is true that you'll lose the file permissions unless you use
some sort of migration utility or script.

On 2004-11-18, Owen Greaves <owen.g@telus.net> wrote:
> This consultant has been
> installing debian without our knowledge after being told we wanted Slackware
> as that is what my current people are familiar with for the most part
> including myself.

If they are really installing something you didn't ask for without
telling you or explaining why beforehand, I think it's time for a
new consultant.

> So they are setting up a Samba box that will have to work
> a number of Windows 2000 Servers (Active Directory).

Define ''work with''. If the W2k boxes are just clients to the
file server, then you likely don't need AD, just an LDAP server
like OpenLDAP. Since you already have NDS, it sounds like, and
are trying to dump Novell, why not go to OpenLDAP directly, and
skip the Microsoft stuff too?

If you do go that route, you won't need PAM, either, and you can
tell your consultant to stuff his Debian in an impolite location.

> The problem with
> migrating Novell File Servers to Samba is the permissions and authentication
> doesn't come over with the data when moved to the new server.

You will likely encounter this problem whether you move to Slackware,
Debian, or any other Samba platform, so there's no reason a priori
to choose Debian there.

> So, I'm trying to confirm what this consultant is telling me and or find
> another solution so we can stick with Slackware.

You haven't really clarified what your needs are and what you
currently have--what are all the clients, what are all the servers,
and who needs access to what from where? A perfectly acceptable
network can be done with OpenLDAP, Samba, Slackware, and W2k, but
perhaps there are other issues that you haven't mentioned that
might suggest using something else.

Oh, and *please* stop top-posting!

--keith

--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom

Owen Greaves wrote:
> I'm moving to a Linux environment in our office and I have been leaning
> toward Slackware as our distro of choice. The consultant we brought in is
> telling me that there are major hassles with Samba & PAM under Slackware.
> Can anyone verify this or is he trying push Debian into our office?

As soon as you need enterprise authentication management, forget Slackware.
PAM will never be included. Which mean that you cannot use Slack in a
kerberos environment without recompilling a lot of stuffs, you can't use it
either _securely_ in an LDAP authentication network.......

Keith Keller wrote:

> On 2004-11-18, Owen Greaves <owen.g@telus.net> wrote:
>> This consultant has been
>> installing debian without our knowledge after being told we wanted
>> Slackware as that is what my current people are familiar with for the
>> most part including myself.
>
> If they are really installing something you didn't ask for without
> telling you or explaining why beforehand, I think it's time for a
> new consultant.
>

Indeed. Installing something different without asking after being told
explicitly what was wanted is a definite no-no.

Makes me wonder what else the guy has fixed notions on.

On Thu, 18 Nov 2004 08:35:00 +0100, Antoine Jacoutot wrote:
> Owen Greaves wrote:
>> I'm moving to a Linux environment in our office and I have been leaning
>> toward Slackware as our distro of choice. The consultant we brought in is
>> telling me that there are major hassles with Samba

Indeed. This doesn't have to do with any OS distro though, although some
may have a GUI configuration frontend. You might want to run "swat" and/or
"webmin" for createing a default to hand-hack further.

>> & PAM under Slackware.

On this your consultant is correct. (But it's unlikely to be needed anyway.)

>> Can anyone verify this or is he trying push Debian into our office?
>
> As soon as you need enterprise authentication management, forget Slackware.

Err, as a server or client?
Whatever happened to NIS and NTLM though?
(Are they not "enterprise" protocols anymore?)

> PAM will never be included.

Good.

> Which mean that you cannot use Slack in a
> kerberos environment without recompilling a lot of stuffs,

Well, maybe so, or maybe not... It just depends upon what kind of role(s)
you want the Slackware powered machine to take within the Kerberos realm.

Here is my little home network KDC (key distribution center) setup:

bash-2.05b$ cat /etc/krb5.conf
# Edited form example shiped with OpenBSD 3.2

[libdefaults]
# Set the realm of this host here
default_realm = TEST.LAN
# Maximum allowed time difference between KDC and this host
clockskew = 300
# Uncomment this if you run NAT on the client side of kauth
# This may be considered a security issue though.
#no-addresses = yes

[realms]
TEST.LAN = {
# Specify KDC here
kdc = kdc.test.lan
}

# This section describes how to figure out a realm given a DNS name
[domain_realm]
.test.lan = TEST.LAN
test.lan = TEST.LAN


### Leave next section out on the clients ###
[kdc]
# The list of addresses to listen for requests on
addresses = 127.0.0.1 192.168.0.100
# This is needed when KDC is started atomatically
require-preauth = no
# DB key
key-file = /var/heimdal/key-file
# Check the addresses in the ticket when processing TGS requests
check-ticket-addresses = TRUE
# Permit tickets with no addresses
allow-null-ticket-addresses = TRUE
# Permit anonymous tickets with no addresses
allow-anonymous = TRUE

[kadmin]
# For a k5 only realm, this will be fine
default_keys = v5

[logging]
# The KDC logs by default, but it's nice to have a kadmind log as well
kadmind = FILE:/var/heimdal/kadmind.log


bash-2.05b$

> you can't use it either _securely_ in an LDAP authentication network.......

There are more ways to most ends (for instance: SSL/TLS). And whatever,
with the implementation flaws in MIT Kerberos as of late... I use Heimdal:

------------------
heimdal.SlackBuild
------------------

#!/bin/sh

NAME=heimdal
CWD=`pwd`

VERSION=0.6.3
ARCH=i586
BUILD=1

if [ ! -d $TMP ]; then
TMP=/tmp
fi

PKG=$TMP/package-$NAME
rm -rf $PKG
mkdir -p $PKG

cd $TMP
tar xzvf $CWD/$NAME-$VERSION.tar.gz

cd $NAME-$VERSION

# Set permissions
find . -type f -exec chmod go-w {} \;
find . -type d -exec chmod 0755 {} \;
chown -R root.root .
chmod -R -s .

# Note - no need for the KDC to support LDAP
CFLAGS="-O2 -march=$ARCH" \
../configure \
--enable-shared=no \
--enable-static=yes \
--disable-otp \
--disable-dynamic-afs \
--without-krb4 \
--without-hesiod \
--without-ipv6 \
--without-openldap \
--with-gnu-ld \
--with-openssl=/usr/bin \
--with-openssl-lib=/usr/lib \
--with-openssl-include=/usr/include/openssl \
--with-readline=/usr/lib \
--with-readline-lib=/usr/lib \
--with-readline-include=/usr/include/readline
--with-x
make
make install DESTDIR=$PKG

# Strip symbols off of binaries
strip $PKG/usr/heimdal/bin/*
strip $PKG/usr/heimdal/sbin/*
strip --strip-unneeded $PKG/usr/heimdal/lib/*.so

# I guess this makes sense
chgrp -R bin $PKG/usr/heimdal/bin
chgrp -R bin $PKG/usr/heimdal/sbin

# Database dir
mkdir -p $PKG/var/heimdal

# Set PATH and MANPATH
mkdir -p $PKG/etc/profile.d
cat << EOF > $PKG/etc/profile.d/heimdal.sh
#!/bin/sh

MANPATH="\$MANPATH:/usr/heimdal/man"
PATH="\$PATH:/usr/heimdal/bin"
if [ x"\$EUID" == x"0" ]; then
PATH="\$PATH:/usr/heimdal/sbin"
fi
EOF
chmod +x $PKG/etc/profile.d/heimdal.sh

# Include a KDC rc-file for the admin to consider
mkdir -p $PKG/etc/rc.d
cat << EOF > $PKG/etc/rc.d/rc.heimdal
#!/bin/sh

heimdal_start() {
if [ -r /etc/krb5.conf -a -x /usr/heimdal/libexec/kdc ]; then
echo "/usr/heimdal/libexec/kdc --config-file=/etc/krb5.conf --detach"
/usr/heimdal/libexec/kdc --config-file=/etc/krb5.conf --detach
fi
}

heimdal_stop() {
killall kdc
}

heimdal_restart() {
heimdal_stop
sleep 1
heimdal_start
}

case "\$1" in
'start')
heimdal_start
;;
'stop')
heimdal_stop
;;
'restart')
heimdal_restart
;;
*)
echo "Usage: \$0 start|stop|restart"
esac
EOF

#
# Documentation :
#
mkdir -p $PKG/usr/doc/$NAME-$VERSION
cp -a NEWS README TODO* config.log \
$PKG/usr/doc/$NAME-$VERSION
mkdir -p $PKG/usr/doc/$NAME-$VERSION/ChangeLog
cp -a ChangeLog* $PKG/usr/doc/$NAME-$VERSION/ChangeLog
mkdir -p $PKG/usr/doc/$NAME-$VERSION/etc
cp -a etc/services.append \
$PKG/usr/doc/$NAME-$VERSION/etc
mkdir -p $PKG/usr/doc/$NAME-$VERSION/doc
cp -a doc/{init-creds,layman.asc,mdate-sh} \
$PKG/usr/doc/$NAME-$VERSION/doc
mkdir -p $PKG/usr/doc/$NAME-$VERSION/doc/standardisation
cp -a doc/standardisation/* \
$PKG/usr/doc/$NAME-$VERSION/doc/standardisation

mkdir -p $PKG/etc
cp krb5.conf $PKG/etc/krb5.conf.example

rm $PKG/usr/heimdal/info/dir
gzip -9 $PKG/usr/heimdal/info/*

mkdir -p $PKG/usr/info
mv $PKG/usr/heimdal/info/* $PKG/usr/info

( cd $PKG/usr/heimdal/man
find . -type f -exec chmod 644 {} \;
find . -type f -exec gzip -9 {} \;
)

mkdir $PKG/install
cat $CWD/slack-desc > $PKG/install/slack-desc

# Create a package out of this
cd $PKG
makepkg -l y -c n ../$NAME-$VERSION-$ARCH-$BUILD.tgz

# Clean up the extra stuff:
if [ "$1" = "--cleanup" ]; then
rm -rf $TMP/$NAME-$VERSION
rm -rf $PKG
fi

--
-Menno.

Menno Duursma wrote:

> There are more ways to most ends (for instance: SSL/TLS). And whatever,
> with the implementation flaws in MIT Kerberos as of late... I use Heimdal:

I do too.
But tell me, how do you manage to login at the console if your
authentication is Kerberos ?
By they way, for password management, NIS is not an option for me.

On 2004-11-18, Antoine Jacoutot <ajacoutot@lphp.org> wrote:
> [...] you can't use [Slackware]
> either _securely_ in an LDAP authentication network.......

If by securely you mean encrypted, then you are completely incorrect.
I have configured a Slackware client to use TLS to initate an SSL
connection with an OpenLDAP server when authenticating via LDAP
configured through NSS. No PAM or Kerberos is required.

--keith

--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom

Keith Keller wrote:
> If by securely you mean encrypted, then you are completely incorrect.

No, I did not mean that.

> I have configured a Slackware client to use TLS to initate an SSL
> connection with an OpenLDAP server when authenticating via LDAP
> configured through NSS. No PAM or Kerberos is required.

But anyway, what I'm interested in is Kerberos support which is not
available without first installing heimdal or MIT then, recompiling all
packages you want them to be kerberos aware.
If PAM was included, it would be much easier. Same goes for people who want
users to authenticate through an sql database, radius.... whatever.
I'm not saying PAM is great, but it sure is practical.

Antoine Jacoutot <ajacoutot@lphp.org> wrote:
> I'm not saying PAM is great, but it sure is practical.

Since you're making unsubstantiated claims on this thread, let me throw in
mine.... Practical, hahaha.

>> I'm not saying PAM is great, but it sure is practical.
>
> Since you're making unsubstantiated claims on this thread, let me throw in
> mine.... Practical, hahaha.

hmm, why do you think his claim is unsubstantial?
how otherwise (without PAM) would you implement a login mechanism using a
usb security token, for example.

I'd never put PAM on a public server, but in closed environments it can be
very usefull.


--
damjan