Subject: passwords longer than 8 characters

From: "Miller.Jonathan" <[email-masked]>
Date: Thu, 26 Jul 2001 14:25:18 -0400

I've got netatalk 1.4 set up and working fine on RedHat 6.2, but I'm
finding there's a problem when people have passwords longer than 8
characters.  Is there some way, maybe through a UAM, to have it accept
longer passwords?  (The end doal is actually to go and authenticate
against an NT domain using pam_smb, which is also set up just fine.  I
just run into problems with these long passwords.)

I hope this isn't a FAQ; I didn't see anything like it in the
FAQ-o-matic, but maybe I just didn't look hard enough.

Thanks,

Jonathan Miller
Bioinformatics System Administrator
NIEHS MicroArray Center (ITSS)

---

From: Thomas Kaiser <[email-masked]>
Date: Thu, 26 Jul 2001 21:48:40 +0200

am 26.07.2001 20:25 Uhr schrieb Miller.Jonathan:

> there's a problem when people have passwords longer than 8 characters.

Support for more than 8 chars in passwords came with DHX authentication.

> Is there some way, maybe through a UAM, to have it accept longer passwords?

If you have a recent AppleShare Client (Apple recommends 3.8.8 if you want
to change you passwords through chooser: <http://til.info.apple.com/techinfo
.nsf/artnum/n60792>) and compiled a recent Netatalk version with DHX
Authentication, things will work as expected. :-)

Regards,

Thomas

---

From: Harald Wagener <[email-masked]>
Date: Fri, 27 Jul 2001 09:59:58 +0200

> Support for more than 8 chars in passwords came with DHX authentication.

Where is this limitation? Is it in the uam from netatalk, or is it built in into
the
chooser? If it is part of the uam, it would be nice to lift that limitation,
because then 
one would be able to authenticate against external services (i.e., LDAP) with
longer passwords.

H.

-- 
Harald Wagener      |                                Systemadministrator 
FCB/Wilkens GmbH    |                              Tel.:+49-40-2881-1252 
An der Alster 42    |                              Fax.:+49-40-2881-1263 
20099 Hamburg       |                         http://www.fcb-wilkens.com

---

From: "Chris Herrmann" <[email-masked]>
Date: Mon, 30 Jul 2001 09:13:29 +1000

Yep - use the pam uam. You'll need some software on the mac to support this
(any mac gurus out there tell us what it is?) I'm pretty sure it's just a
patch from apple.

Cheers,

chris

-----Original Message-----
From: Miller.Jonathan [mailto:[email-masked]]
Sent: Friday, 27 July 2001 04:25
To: [email-masked]'
Subject: passwords longer than 8 characters

Thanks,

Jonathan Miller

---

From: "Chris Herrmann" <[email-masked]>
Date: Mon, 30 Jul 2001 09:42:39 +1000

It's a two part thing - you need to use dhx authentication, **and** you need
to be using the latest version of appletalk (see earlier email from
someone).

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Harald
Wagener
Sent: Friday, 27 July 2001 18:00
To: Thomas Kaiser
Cc: Miller.Jonathan; [email-masked]'
Subject: Re: passwords longer than 8 characters

> Support for more than 8 chars in passwords came with DHX authentication.

Where is this limitation? Is it in the uam from netatalk, or is it built in
into
the
chooser? If it is part of the uam, it would be nice to lift that limitation,
because then
one would be able to authenticate against external services (i.e., LDAP)
with
longer passwords.

H.

---

From: Thomas Kaiser <[email-masked]>
Date: Mon, 30 Jul 2001 11:36:48 +0200

Hi,

[quotings rearranged :-/ ]

>> Where is this limitation?

With cleartext and 2-way randnum authentication there was an limitation in
the passwords length. This limitation no longer exists when using DHX
authentication, which is built into recent AppleShare clients (so you can
use passwords with more than 8 chars without modifiying anything on your
mac)

If a Mac contants an AFP server then the server will answer the macs
FPGetSrvrInfo request with a list of UAMs it can handle. Some of them are
built-in, some of them may not. So the AppleShare client looks into the
system folder for UAMs. If there is an UAM, that matches the servers then it
will be used.

If you want to connect to NTs Services for Macintosh for example, you have
the ability to use cleartext and 2way-randnum (without dropping uam files
into the macs system folder) or you copy the MS-UAM to your mac and can use
an authentication method that allows passwords with 14 chars in length and
stronger encryption.

There are also Patches available that can be used with AppleShare IP.
Afterwards you can authenticate via PGP with your server. :-)
 
>> Is it in the uam from netatalk, or is it built in into the chooser?

You have to search on both ends of the cable ;-)

With AppleShare Client 3.6 (or 3.7? -- can't remember) Apple supported
third-party UAMs. What you mean is the servers side, I think. When using the
dhx uam with netatalk and recent AppleShare Clients on your Macs (3.8.6 or
3.8.8) then you will use automatically DHX authentication between client and
server. So you will be able to use longer passwords.

>> If it is part of the uam, it would be nice to lift that limitation,
>> because then one would be able to authenticate against external services
>> (i.e., LDAP) with longer passwords.

This can be done already.

> to be using the latest version of appletalk (see earlier email from

AppleTalk is not the right word. AppleShare Client sounds better ;-)

(Please remember that with AFP 3.0 there will be no longer support for AFP
-- aka AppleShare -- over AppleTalk at all)

Regards,

Thomas

---

From: Harald Wagener <[email-masked]>
Date: Mon, 30 Jul 2001 11:45:09 +0200

> system folder for UAMs. If there is an UAM, that matches the servers then it

[snip] 

> > to be using the latest version of appletalk (see earlier email from

But You cannot use DHX if authentication is passed to some external mechanism by 
PAM. And if You put uams_dhx.o in the list of allowable methods, the chooser
(appleshare client) will 
choose that of it´s own, and authentication against the ldap server won't work
anymore. 
Or am I wrong here?

[snip]
> Thomas

Regards,
	Harald