[BBLISA] Single sign-on help requested

Joshua Putnam Joshua.Putnam at intersystems.com
Thu Aug 23 18:19:33 EDT 2007 

I'm not sure what you mean by "sniffed kerberos passwords."  Kerberos
never places any passwords on the wire, encrypted or not, so how would
you sniff them?

I've done extensive testing of both home-rolled AD authentication to
Unix and Commercial products (Centrify, Vintela Authentication Services,
aka. VAS).  The home-rolled solutions are cumbersome to implement and
require patches/changes to system libraries, which may not be a problem
in production environments but is unacceptable in most development
environments.  Home rolled solutions, depending on pam_nss, are also not
available for some older Unix platforms.

The biggest gotcha is the vulnerability of forwardable Kerberos tickets
to theft by any user with root priviledges.  If a user has root, they
can steal any other user's ticket cache from /tmp or the user's homedir
on a Unix system and use it to impersonate that user anywhere else on
the network.  But with forwardable tickets disabled (from the AD domain
controller), single-sign on will only work from a Windows client to the
first Unix box.  A user will not be able to then single-sign on to a
second Unix box from there. 

SAMBA/Winbind also has significant limitations on the assignment of
consistent UIDs on multiple Unix/Linux hosts. 

Of course, you could audit the Unix boxes with forwardable tickets from
another, secure system, to see if anyone is abusing the tickets.

:)

Joshua Putnam
Sr. Unix Administrator
Intersystems Corporation
1 Memorial Drive
Cambridge, MA 02142
 

 

-----Original Message-----
From: bblisa-bounces at bblisa.org [mailto:bblisa-bounces at bblisa.org] On
Behalf Of Sean OMeara
Sent: Thursday, August 23, 2007 10:09 AM
To: Scott Ehrlich
Cc: bblisa at bblisa.org
Subject: Re: [BBLISA] Single sign-on help requested

Also the use of NTLM makes sniffed passwords extremly easy to crack
using rainbow tables

http://www.antsight.com/zsl/rainbowcrack/

sniffed kerberos passwords are still vulnerable to an offline
dictionary/brute force attack, but you you cant use the neato time/space
tradeoff like you can on ntlm


On 8/23/07, Sean OMeara <someara at gmail.com> wrote:
> To paraphrase my previous post:
>
> 1) It's not true single sign on, only unified passwords
>
> 2) the passwords will fall out of sync between the windows and linux 
> side unless they're changed from windows
>
>
> On 8/23/07, Scott Ehrlich <scott at mit.edu> wrote:
> > Sorry to top-post, but it is my intention to use samba on the RH 5 
> > box to act as my domain controller.  I thought I read somewhere that

> > accounts
> > (user/pass) can be easily synced ldap and samba, including home 
> > dirs?  Am I wrong?
> >
> > Thanks.
> >
> > Scott
> >
> > On Thu, 23 Aug 2007, Sean OMeara wrote:
> >
> > > Scott:
> > >
> > > If you want TRUE single sign on capabilities and you intend to 
> > > involve Windows in any way, you absolutely have to use an Active 
> > > Directory as your kerberos KDC. There is ABSOLUTELY NO WAY around 
> > > it. (unless of course you're adventurous enough to use samba4)
> > >
> > > By TRUE sigle sign on I mean:
> > > passwordless authentication to network resources (ssh, samba 
> > > shares/
> > > NFSv4 servers, (homedirs!) apache/mod_spnego, jabber/sasl, 
> > > ssh/gssapi, ldap/sasl, AFS, the works) from both the XP clients 
> > > and the linux/unix clients.
> > >
> > > The only way to do it is:
> > > authentication
> > > *Active Directory KDC + LDAP + RPC for windows 
> > > authentication/authorization *Active Directory KDC for unixland 
> > > kerberos authentication
> > >
> > > authorization
> > > * Active Directory ldap server schema extensions (ms SFUv3.5) to 
> > > house the unix posix data (uid, gid, homedir, shell, supplemental 
> > > gids
> > > ((/etc/group))
> > >
> > > or
> > > * seperate ldap resource (openldap, fedoraDS) dedicated to housing

> > > the unix posix data
> > > * scripting fun to keep your groups in order
> > >
> > > The reason for this lies in the way Windows handles the 
> > > authorization part of the sign on process. ( unix clients dig 
> > > their authorization data out of ldap, windows clients have it 
> > > returned in the PAC field within their kerberos ticket)
> > >
> > > It's actually not that bad really.... AD can be manipulated from 
> > > the linux command line via samba tools (net ads user add, net ads 
> > > group delete, etc)
> > >
> > > ......
> > >
> > > now barring all that... if what you meant by "single sign on" is 
> > > actually "unified passwords", then you can do it without AD using 
> > > samba and ldap no problem. (well, only small problems anyway)
> > >
> > >
> > > No matter what you'll have to maintain TWO password databases, one

> > > for windows, and one for everyone else.
> > >
> > > The standard configuration for this is one of the two of these:
> > >
> > > a)
> > > authentication
> > > * Windows NT4 style NTLMv2 Samba v3 authentication
> > > * Samba looks at an ldap backend for:
> > > sambaLMPassword:
> > > sambaNTPassword:
> > >
> > > * unixland clients attempt a bind to the ldap server, testing
against the field:
> > > userPassword
> > >
> > > authorization:
> > > Samba looks at an ldap backend for, and then returns to the 
> > > windows machine via rpc:
> > > sambaAcctFlags
> > > sambaPrimaryGroupSID:
> > > sambaLogonTime:
> > > sambaPasswordHistory
> > > sambaSID
> > > sambaPwdCanChange:
> > > sambaAcctFlags:
> > > sambaPwdLastSet:
> > > sambaPwdMustChange
> > >
> > > b)
> > > authentication:
> > > samba stuff for windows
> > > unixland looks to an MIT or Heimdal KDC for authentication
> > >
> > > authorization:
> > > same stuff for windows
> > > unixland looks in the ldap directory for:
> > > uidNumber
> > > gidNumber
> > > homeDirectory
> > > groups information
> > >
> > > The consequences of the dual password sources will boil down to
this:
> > >
> > > When a user changes his password via the unix passwd utility, it 
> > > will only change:
> > > the userPassword field in the ldap record or the password on the 
> > > kerberos principal.
> > >
> > > Windows users change it via samba, which can call a script to 
> > > change both the sambaNTPassword fields and the userPassword fields

> > > in the ldap record.
> > >
> > > I'm not sure if its possible to have samba call a script to set 
> > > the sambaNTPassword and change the kerberos princ.
> > >
> > > PS if you're going to get kerberos involved in any way, every 
> > > machine needs to be able to resolve their FQDN, both forward and 
> > > reverse. This means you either need to maintain lots of /etc/hosts

> > > entries in the
> > > form:
> > >
> > > 127.0.0.1        localhost        localhost.localdomain
> > > 127.0.0.1        somebox.mit.edu sombox
> > >
> > > or proper 1 to 1 mapped forward and reverse DNS.
> > >
> > > If your machine can't correctly do hostname and hostname -f, 
> > > kerberos will NOT WORK.
> > >
> > > .....
> > >
> > > To answer your questions about the homedirs:
> > >
> > > You want a fileserver running both samba and NFS.
> > > Windows clients will use roaming profiles to mount their homedirs 
> > > via SMB, linux will use NFS.
> > >
> > > Your error messages look like your ldap server isnt running.
> > >
> > > -s
> > >
> > >
> > >
> > > PS I live around the corner from MIT and I'm much better at 
> > > explaining things when people buy me ronnie burgers ;)
> > >
> > > -s
> > >
> > >
> > > On 8/23/07, Scott Ehrlich <scott at mit.edu> wrote:
> > >> I have a RHEL5 Server and some dual-boot XP/CentOS 5 systems
(Linux systems all
> > >> 64-bit).   All Linux is out-of-box, with all packages, minus
international
> > >> languages, installed.  No patching has been done.
> > >>
> > >> On the server, I selected system-config-authentication and 
> > >> enabled LDAP for User Information, Kerberos, LDAP, and SMB for 
> > >> Authentication, and Shadow and
> > >> MD5 Passwords, along with Authenticate system accounts by network

> > >> services for Options.
> > >>
> > >> All machines are on an isolated LAN, with no DNS server (I could 
> > >> always enable and configure DNS on the server if it helps the
cause).
> > >>
> > >> I also don't know if it matters, but the server is running the 
> > >> virtualization kernel (xen), but the clients are not.
> > >>
> > >> I only have LDAP service enabled on the server.   Kerberos
services are enabled
> > >> on both client and server.
> > >>
> > >> I tweaked the LDAP and Kerberos settings using the CentOS/RH 
> > >> GUIs, and have the clients looking to the RH box for
authentication.
> > >>
> > >> I also have the firewall enabled, but am letting kerberos and 
> > >> ldap ports through as tcp.
> > >>
> > >> During a login test, /var/log/messages on the client showed:
> > >>
> > >> lin1 gdm[pid]: nss_ldap: failed to bind to LDAP server
ldap://192.168.1.100:
> > >> Can't contact LDAP server
> > >>
> > >> lin1 gdm[pid]: nss_ldap: reconnecting to LDAP server (sleeping 32
seconds)...
> > >>
> > >> lin1 dbus-daemon: nss_ldap: failed to bind to LDAP server
ldap://192.168.1.100:
> > >> Can't contact LDAP server
> > >>
> > >> lin1 dbus-daemon: dss_ldap: failed to bind to LDAP server...
> > >>
> > >> lin1 xfs: ...
> > >>
> > >>
> > >> During boot time, Starting system message bus: [long pause] then 
> > >> error messages about DB_CONFIG and /var/lib/ldap, the usual 
> > >> cannot find DB_CONFIG in /var/lib/ldap, showing the example.com 
> > >> instead of my customized ldap settings, etc.
> > >>
> > >> I've checked openldap.org, but I figured if the configuration 
> > >> appears to be simplified via an included GUI, I shouldn't have 
> > >> much trouble gettigns things going.
> > >>
> > >> Anyway, what am I missing?   Anything special RH 5 is doing
compared to the
> > >> openldap docs?
> > >>
> > >> Both servers have been rebooted since adding the respective ports

> > >> in the firewall.
> > >>
> > >> The goal is a to permit my test user, created on the server, to 
> > >> sit at a workstation, boot into either Linux or XP, and get their
home directory.
> > >>
> > >> Ideally, the server only needs to consist of one account for 
> > >> them, which they get upon login on the workstation.
> > >>
> > >> I want to highly restrict _any_ third-party tools/apps/etc.   I
will be happy
> > >> to take suggestions and leads, but I want to try and rely on what

> > >> RH has provided.
> > >>
> > >> Thanks for any insight/help.
> > >>
> > >> Scott
> > >>
> > >> _______________________________________________
> > >> bblisa mailing list
> > >> bblisa at bblisa.org
> > >> http://www.bblisa.org/mailman/listinfo/bblisa
> > >>
> > >
> >
>

_______________________________________________
bblisa mailing list
bblisa at bblisa.org
http://www.bblisa.org/mailman/listinfo/bblisa

More information about the bblisa mailing list