Have you tried
sasl_pwcheck_method: saslauthd
sasl_mech_list: PLAIN GSSAPI
Our pine users connect useing a Kerb5 ticket.
Our other users (like Apple Mail) send us a username/password over a
secure connection.
They are then validated by saslauthd.
-Patrick
On Aug 25, 2005, at 12:42 PM, Tim
On Thu, 25 Aug 2005, Tim Strobell (Contractor) wrote:
> > We need to support Kerberos credentials directly from the clients; pam_krb5
> > only proxies the username and passwords to the KDC for authentication.
>
> I use gssapi authentication with Mutt against Cyrus using the actual
> Kerberos cr
> > We need to support Kerberos credentials directly from the clients; pam_krb5
> > only proxies the username and passwords to the KDC for authentication.
>
> I use gssapi authentication with Mutt against Cyrus using the actual
> Kerberos credentials, so it would seem to work.
Of course -- b
On 08/24 19:27, Tim Strobell (Contractor) wrote:
> We need to support Kerberos credentials directly from the clients; pam_krb5
> only proxies the username and passwords to the KDC for authentication.
I use gssapi authentication with Mutt against Cyrus using the actual
Kerberos credentials, so it w
> > Can Cyrus support multiple authentication methods? (Although SASL
> > provides many options, it appears that IMAP/POP supports only one.)
> > We would like to provide authentication via both Kerberos 5 (GSSAPI) and
> > LDAP (via saslauthd); users may choose
On Wed, 2005-08-24 at 15:18 -0400, Tim Strobell (Contractor) wrote:
> Can Cyrus support multiple authentication methods? (Although SASL provides
> many
> options, it appears that IMAP/POP supports only one.)
>
> We would like to provide authentication via both Kerberos 5 (G
Can Cyrus support multiple authentication methods? (Although SASL provides many
options, it appears that IMAP/POP supports only one.)
We would like to provide authentication via both Kerberos 5 (GSSAPI) and LDAP
(via saslauthd); users may choose whichever method is most convenient for
them
On Fri, 7 Nov 2003, Craig Ringer wrote:
> > GSSAPI/KERBEROS_V4 rely on the Kerberos Domain Controllers (KDC).
>
> Yeah. I left that off because it seemed pretty obvious, but p'haps it's
> best included.
It struck me as the same as a "Windows NT" authentication source.
> I personally like using P
>> This is much better. I'd probably put the mechanisms outside of the
>> libsasl box, since they are (almost always) loaded dynamicly.
>
> OK.
>
>> NTLM can use either Windows NT networking or the auxprop plugins.
>
> I don't quite get you there. I'll have a deeper look into the NTLM
> support an
Craig Ringer wrote:
This is much better. I'd probably put the mechanisms outside of the
libsasl box, since they are (almost always) loaded dynamicly.
OK.
NTLM can use either Windows NT networking or the auxprop plugins.
I don't quite get you there. I'll have a deeper look into the NTLM
supp
This is much better. I'd probably put the mechanisms outside of the
libsasl box, since they are (almost always) loaded dynamicly.
OK.
NTLM can use either Windows NT networking or the auxprop plugins.
I don't quite get you there. I'll have a deeper look into the NTLM
support and see if I get a be
On Thu, 6 Nov 2003, Craig Ringer wrote:
> I'm about as far from an expert on Cyrus as there is, so apologies if
> I'm dead wrong about something. I do think that a document like this
> will be useful in showing people how things fit together, and the
> various different "paths" through which Cyrus
Hi Craig,
I just wanted to say that such a 'big picture' is VERY useful. One picture
says more than thousand words.
Thanks,
Simon
> I posted a little while ago with a graphical map of the Cyrus
> authentication methods - missing the Mechanism layer completely.
> I th
I posted a little while ago with a graphical map of the Cyrus
authentication methods - missing the Mechanism layer completely.
I think I have a better understanding of that now, and have
updated the document appropriately. Comments would be appreciated.
I'm about as far from an expert on Cyr
Ken Murchison wrote:
Craig, this is a good start, but as Rob said, you've left out the
mechanism layer.
Hmm... thanks. It appears that there's something lacking in my
understanding of the authentication scheme, but the posts on this thread
have given me some idea where to look and learn. I'll inc
On Fri, 31 Oct 2003, Craig Ringer wrote:
> Rob Siemborski wrote:
> > I'd also be much more inclined to accept this into the distribution if it
> > was in an easily modifiable format (at this point, I suspect that means
> > xfig, but if you have another suggestion I'm willing to listen).
>
> The cu
On Thu, 30 Oct 2003, Ken Murchison wrote:
> Craig Ringer wrote:
>
> > I'd really appreciate feedback on this - what have I missed, do I have
> > anything just plain wrong, etc. I've left out some things - like the
> > 'shadow' mechanism of saslauthd - that seem best solved using other
> > methods
Craig Ringer wrote:
I'd really appreciate feedback on this - what have I missed, do I have
anything just plain wrong, etc. I've left out some things - like the
'shadow' mechanism of saslauthd - that seem best solved using other
methods (getpwent in that case). Also left out are the specific-ven
On Thu, 30 Oct 2003, Craig Ringer wrote:
> I'd really appreciate feedback on this - what have I missed, do I have
> anything just plain wrong, etc. I've left out some things - like the
> 'shadow' mechanism of saslauthd - that seem best solved using other
> methods (getpwent in that case). Also lef
Hi folks
I've noticed a fair few questions on the list since I've been subscribed
that ask about authentication. I'd go so far as to say that it's the #1
or #2 topic (behind migration or mailbox recovery). Perhaps I can do
something to help, as a non-coder.
I know that when setting up Cyrus I
On Thu, 2 Oct 2003, Etienne Goyer wrote:
> On Wed, Oct 01, 2003 at 04:27:58PM -0400, Rob Siemborski wrote:
> > On Wed, 1 Oct 2003, Etienne Goyer wrote:
> > > A question : is the 'proxy_authname' required to be admin on the
> > > backend? Could it be just in proxyservers ?
> >
> > Yes. That's the
On Wed, Oct 01, 2003 at 04:27:58PM -0400, Rob Siemborski wrote:
> On Wed, 1 Oct 2003, Etienne Goyer wrote:
> > A question : is the 'proxy_authname' required to be admin on the
> > backend? Could it be just in proxyservers ?
>
> Yes. That's the idea, in fact.
Just to clarify : yes it have to be
the authentication process between the front and the
back ends. We would like to avoid using Kerberos if at all possible
being as we do not have an existing Kerberos installation. What
authentication methods would be best suited for this environment?
Kerberos is best suited to this
On Wed, 1 Oct 2003, Etienne Goyer wrote:
> Replace 'backend1' and 'backend2' with the actual name of your backend.
> Also, the user specified in 'proxy_authname' must be authenticable on
> the backend (by auxprop, most likely, since it connect with DIGEST-MD5).
>
> A question : is the 'proxy_authn
ar about the authentication process between the front and the
> back ends. We would like to avoid using Kerberos if at all possible
> being as we do not have an existing Kerberos installation. What
> authentication methods would be best suited for this environment?
The frontend authentic
tion process between the front and the
> back ends. We would like to avoid using Kerberos if at all possible
> being as we do not have an existing Kerberos installation. What
> authentication methods would be best suited for this environment?
Kerberos is best suited to this enviornm
like to avoid using Kerberos if at all possible
being as we do not have an existing Kerberos installation. What
authentication methods would be best suited for this environment?
--
Anthony Mayes
UNIX Server Administration
Southern Illinois University Edwardsville
[EMAIL PROTECTED]
Assuming you are talking about where SASL gets
its information from, you can use all except
for passwd and shadow backends.
If you are talking about how a client
authenticates to the IMAP server, then you
can use all methods available.
-- Michael --
On Tue, 2001-10-09 at 10:08, Robert McCall
28 matches
Mail list logo
