[BBLISA] Single sign-on help requested

Fri Aug 24 09:30:06 EDT 2007

Scott:

Thanks for the link and the information.  Clearly, from the links I
found under the search you sent, public keys are more secure than
passwords.  This is also true for non-kerberized SSH environments.

Of course, the weakness in password authentication schemes applies
mostly to weak passwords and Windoze does allow you to specify an
arbitrarily complex password scheme.  The O'Reilly book, Practical Unix
and Internet Security, has a great chapter on strong vs.. weak
passwords.  System administrators who rely on password-based
authentications schemes MUST enforce strong passwords, password aging,
etc.

At our site, the reason that we felt turning off forwardable tickets was
not an option is that our users frequently need to connect from Unix
machine A to Unix machine B.  If forwardable tickets are turned off,
then a user connecting from A to B directly must use a protocol such as
SSH, which (although encrypted) does put the password on the wire, and
thus is vulnerable to the rainbow table attack.   Worse still, if any
unencrypted protocols (ftp, telnet, rlogin, etc.) are left open on even
a single system, you will now have AD passwords on the wire in
cleartext.

Of course, you can enforce a "no insecure protocols" policy, enforcing
ssh, scp and sftp over telnet, rsh, rcp and ftp.   You could also set
your users up with ssh keys and disable ssh password authentication.
But, at that point, it does not appear that you have gained much of
anything over and above what you would get from a pure ssh
authentication policy, without AD authentication in the picture.

What do you think?

Regards,

Josh

P.S. I see you work across the street, at MIT.  Care to do lunch
sometime?

-----Original Message-----
From: Sean OMeara [mailto:someara at gmail.com <mailto:someara at gmail.com> ]
Sent: Friday, August 24, 2007 7:42 AM
To: Joshua Putnam
Cc: Scott Ehrlich; bblisa at bblisa.org
Subject: Re: [BBLISA] Single sign-on help requested

What I meant by "sniffed kerberos passwords" was "sniffed kerberos
exchanges"
You can still run an offline dict/brute force on it.

http://www.google.com/search?hl=en&q=kerberos+%22looks+like+a+timestamp%
22&btnG=Search
<http://www.google.com/search?hl=en&q=kerberos+%22looks+like+a+timestamp
%22&btnG=Search> 

turning off forwardable tickets is annoying only if you've every been
used to having them! %99.99r users wont notice or care that they're off.

And yes, winbind is the devil. =)

-s

On 8/23/07, Joshua Putnam <Joshua.Putnam at intersystems.com> wrote:
> 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
<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/
<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
<http://www.bblisa.org/mailman/listinfo/bblisa> 
> > > >>
> > > >
> > >
> >
>
> _______________________________________________
> bblisa mailing list
> bblisa at bblisa.org
> http://www.bblisa.org/mailman/listinfo/bblisa
<http://www.bblisa.org/mailman/listinfo/bblisa> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.bblisa.org/pipermail/bblisa/attachments/20070824/2bfab204/attachment.htm 