Hi,
Could you please help me to resolve this issue!
When i want to login to the RHEL 7.5 machine with AD account, i get
permission denied:
`Permission denied, please try again.`
password for the user is correct, have tried it multiple times.
Log for sshd:
[root@azrclchefvm01 ~]# tail
It is resolved now.
we had some policies in place to prevent users from login in to systems if
they are not part of certain groups.
sssd works fine.
thanks
On Mon, Jul 23, 2018 at 12:07 PM, Jakub Hrozek wrote:
> On Mon, Jul 23, 2018 at 07:33:53AM -0700, Farshid Mahdavipour wrote:
> > thanks
Hi All!
I am running into an issue where groups cannot be resolved upon login.
All servers on CentOS 6 work fine, so this is isolated to newer sssd
version on CentOS 7.
[user@snoopy ~]$ id
uid=11012(user) *gid=1001* *groups=1001*,10(wheel),1102
[user@snoopy ~]$ getent -s sss passwd user
On Mon, Jul 23, 2018 at 11:08:54AM -0400, sssdusers.20.retin...@spamgourmet.com
wrote:
> Unfortunately it seems to not be so easy:
> rtadmin@ubt18-test:~$ cat /etc/nsswitch.conf
> ...
> #passwd: compat systemd sss
> #group: compat systemd sss
> passwd: files sss
> group:
On Mon, Jul 23, 2018 at 07:33:53AM -0700, Farshid Mahdavipour wrote:
> thanks Jacob,
> I set the log level to 6 in sssd.conf. here is the result:
>
> [root@azrclchefvm01 ~]# tail /var/log/sssd/*
>
> ==> /var/log/sssd/gpo_child.log <==
>
> (Mon Jul 23 13:50:58 2018) [[sssd[gpo_child[69656
On Mon, Jul 23, 2018 at 12:05:49PM -0400, Mario Rossi wrote:
>
> I am seeing similar issues on CentOS 7, where groups, including primary
> group, cannot be looked up. This is really bad when other services depend on
> group lookups, for example sshd match group statements for enabling
>
Perhaps this is a caching issue? I do have several domains configured,
and each domain has development-wholesale name with different GID. Is
the domains cache configured/hased based on the group name ?
Thanks
On 07/23/2018 12:05 PM, Mario Rossi wrote:
I am seeing similar issues on CentOS
I am seeing similar issues on CentOS 7, where groups, including primary
group, cannot be looked up. This is really bad when other services
depend on group lookups, for example sshd match group statements for
enabling tcpforwarding which otherwise is disable globally, iptables
group lookups (
Unfortunately it seems to not be so easy:
rtadmin@ubt18-test:~$ cat /etc/nsswitch.conf
...
#passwd: compat systemd sss
#group: compat systemd sss
passwd: files sss
group: files sss
shadow: files sss
gshadow:files
...
rtadmin@ubt18-test:~$ getent
thanks Jacob,
I set the log level to 6 in sssd.conf. here is the result:
[root@azrclchefvm01 ~]# tail /var/log/sssd/*
==> /var/log/sssd/gpo_child.log <==
(Mon Jul 23 13:50:58 2018) [[sssd[gpo_child[69656 [main] (0x0020):
gpo_child failed!
(Mon Jul 23 14:25:36 2018)
Jakub,
again thankyou for your reply. I am still debugging this one. I think I
have narrowed it down to a PAM configuration, after I ran sssd with a high
debug level.
For anyone following this thread:
/usr/sbin/ssshd -ddd
The failure I get is: PAM: do_pam_account pam_acct_mgmt = 4 (System
Mark, for information you can increase the mumber of retries by
reconnection_retries = N
However that does not help you with your problem!
On 23 July 2018 at 04:05, Mark Johnson wrote:
> I've been going around in circles with this for days and I'm stuck. I'm
> trying to run up a new AD
Just an update. The fix for me is setting this in the pam stanza
pam_response_filter = ENV:KRB5CCNAME
On 19 July 2018 at 12:56, John Hearns wrote:
> Jakub,
> again thankyou for your reply. I am still debugging this one. I think I
> have narrowed it down to a PAM configuration, after I ran sssd
> On 19 Jul 2018, at 15:37, Spike White wrote:
>
> All,
>
> I fear I may be blocked. I responded to an email thread, with an email that
> had two small attachments.
>
> That was wrong. I read the mailing list by-laws and I realize that was
> wrong. I will not repeat that offense. As
> On 23 Jul 2018, at 04:05, Mark Johnson wrote:
>
> I've been going around in circles with this for days and I'm stuck. I'm
> trying to run up a new AD environment with only Samba 4.8.3 servers that
> we'll authenticate user server access against via SSSD/LDAP using a simple
> bind. All
> On 22 Jul 2018, at 22:47, Farshid Mahdavipour wrote:
>
> Hi,
>
> I have configured sssd.service to authenticate to AD on RHEL 7.5 and i have
> successfully joined the rhel machine to AD.
> but i cannot login to the machine with the AD account.
>
> here is the error when i try to login
> On 22 Jul 2018, at 20:49, Spike White wrote:
>
> I can't replicate that "duplicate domains" situation any more. (I thought
> I'd saved that sssd.conf file, but it doesn't exhibit the same behaviour).
>
> Here are the logs for a specific account failing to look up all groups with
>
Unfortunately these tests don’t have an option to raise the debug level so
stepping throught them with gdb is the only option I’m afraid..
> On 20 Jul 2018, at 20:56, Andreas Hasenack wrote:
>
> What I figured out so far is that this is a test that is enabled if
> you have cmocka installed,
18 matches
Mail list logo
