search for: successull

Hi, As per my discussion with cmouse on irc, I'm currently just using dovecot for its auth mechanism, etc capabilities (alas, Exim does not support argon directly). Tis a fun little side project. :) I have the config pared down as far as I think is reasonable (see below) and all is working well except that dovecot is very silent. Errors hit the logs but I would appreciate seeing successful

On Sat, Aug 03, 2019 at 11:27:24AM -0600, Michael Slusarz wrote: > > Errors hit the logs but I would appreciate seeing successful auths > > happen for the additional piece of mind. Cmouse and I couldn't > > find a way to do it on irc and it appears that the capability is > > missing. Successul /logins/ can be logged but auths, by themselves, > > cannot. > >

> On August 2, 2019 9:35 PM AP via dovecot <dovecot at dovecot.org> wrote: > > As per my discussion with cmouse on irc, I'm currently just using > dovecot for its auth mechanism, etc capabilities (alas, Exim does > not support argon directly). Tis a fun little side project. :) > > I have the config pared down as far as I think is reasonable (see > below) and all

...th [success=1 default=ignore] pam_winbind.so krb5_auth > > krb5_ccache_type=FILE cached_login try_first_pass > > > > Change that one to > > auth [success=1 default=ignore] pam_winbind.so krb5_auth > > try_first_pass Try again, put it back again after a successull > > login without messages. > > > Done, that but still get the warning even with the shorter > version. Never able to logon without the warning, so put it back > anyway. The only way I have found not to get the message is to remove > the krb5_auth (and the other ones) co...

...see a line like : > auth [success=1 default=ignore] pam_winbind.so krb5_auth > krb5_ccache_type=FILE cached_login try_first_pass > > Change that one to > auth [success=1 default=ignore] pam_winbind.so krb5_auth try_first_pass > Try again, put it back again after a successull login without messages. > Done, that but still get the warning even with the shorter version. Never able to logon without the warning, so put it back anyway. The only way I have found not to get the message is to remove the krb5_auth (and the other ones) completely. But then we are not...

On Sat, 21 Jul 2018 18:59:08 +0100 Rowland Penny via samba <samba at lists.samba.org> wrote: > On Sat, 21 Jul 2018 18:30:48 +0100 > Roy Eastwood via samba <samba at lists.samba.org> wrote: > > > Thanks Rowland. > > > > > -----Original Message----- > > > From: samba [mailto:samba-bounces at lists.samba.org] On Behalf Of > > > Rowland

...am.d/common-auth You should see a line like : auth [success=1 default=ignore] pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass Change that one to auth [success=1 default=ignore] pam_winbind.so krb5_auth try_first_pass Try again, put it back again after a successull login without messages. When this is done. Now go clear the kerberos cache. Run : klist -ef Check the ETYPES and Flags. Now mail us back with the results. Above should determine if its and old kerberos cache problem or ntp problem. Greetz, Louis > -----Oorspronkelijk bericht----...

Hi, SSH brute force attacks seem to enjoy increasing popularity. Call me an optimist or a misrouted kind of contributer to the community, but on our company server I actually go through the logs and report extreme cases to the providers of the originating IP's. With the increasing number of these attacks, however, I have now decided that it's better to move the SSHd to a different

I''m not sure if this is a problem with the iscsitarget or zfs. I''d greatly appreciate it if it gets moved to the proper list. Well I''m just about out of ideas on what might be wrong.. Quick history: I installed OS 2008.05 when it was SNV_86 to try out ZFS with VMWare. Found out that multilun''s were being treated as multipaths so waited till SNV_94 came out to