[BBLISA] Single sign-on help requested

Fri Aug 24 07:42:09 EDT 2007

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

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] 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
>