[SSSD-users] sss_obfuscate and conf.d

[Mario Rossi]

Hi sssd users!

I am trying to encrypt a password via sss_obfuscate , but the binary 
refuses to work to conf.d/ folder configs


root@sd7[/etc/sssd]# sss_obfuscate -d 'LDAP' -f sssd.conf.se
Enter password:
Re-enter password:
No such domain LDAP


If I append the contents of conf.d/LDAP.conf to sssd.conf.se, it works 
as expected


root@sd7[/etc/sssd]# sss_obfuscate -d 'LDAP' -f sssd.conf.se
Enter password:
Re-enter password:
root@sd7[/etc/sssd]#

root@sd7[/etc/sssd]# rpm -q sssd
sssd-1.16.2-13.el7_6.5.x86_64

root@sd7[/etc/sssd]# cat /etc/centos-release
CentOS Linux release 7.6.1810 (Core)

Thanks

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: problems with expiring password

[Mario Rossi]

You could expire the account, and not the password. Not the most elegant 
way, but I could not find any other way to implement password expiry. I 
did try it a while back on a much older version, so I can't  tell if 
latest code still supports it. All I needed to have in OpenLDAP is 
shadowExpire and no other "shadow" attributes.


sssd.conf

[pam]

pam_verbosity = 1
pam_pwd_expiration_warning = 21
pam_account_expired_message = Your LDAP password has expired, please use 
selfservice portal to change your LDAP password



[domain/xyz]

# SET Account expiration to shadowAccount
ldap_account_expire_policy = shadow
ldap_user_shadow_expire    = shadowExpire
# shadowExpire: days since Jan 1, 1970 that account is disabled: $ echo 
$(($(date --utc --date "$1" +%s)/86400))


# SET Password expiration to none
ldap_pwd_policy = none
ldap_access_order = filter, expire




On 10/31/18 10:26 AM, Bartłomiej Solarz-Niesłuchowski wrote:

Dear List,

On my network we use ldap to "aging" password.


Every user is definied in ldap server (openldap) with 5 attributes:

shadowLastChange: 15308
shadowInactive: 30
shadowMin: 0
shadowMax: 120
shadowWarning: 30


the sssd uses 6 attributes:


    shadowLastChange
    shadowMin
    shadowMax
    shadowWarning
    shadowInactive
    shadowExpire

We have NO shadowExpire attribute (in mathematical point of view 
shadowExpire = shadowLastChange+shadowLastChange).



So how can we use sssd with password "aging" option?


Best Regards


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: id: cannot find name for group ID

[Mario Rossi]

Hi,

Any idea what to look for on this issue ?

Thanks

On 07/24/2018 04:33 PM, Mario Rossi wrote:

Should I sanitize the logs and send them over ?
Thank you

On 07/23/2018 05:26 PM, Mario Rossi wrote:

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
user:*:11012:1001:User Name:/home/user:/bin/bash

However, a quick lookup against the group:

[user@snoopy ~]$ *getent -s sss group security*
security:*:1001:user

Subsequent id lookup works:

[user@snoopy ~]$ id
uid=11012(user) *gid=1001(security) 
**groups=1001(security)*,10(wheel),1102



Sudo also complains about the user, even after above command succeeds

[user@snoopy ~]$*sudo su -*
*sudo: unknown uid 11012: who are you?*


A few seconds later sudo is no longer confused:

[user@snoopy ~]$*sudo su -*
*LDAP OnePassword for **user**:*
root@snoopy[~]#


SSSD config:

[sssd]
config_file_version = 2
sbus_timeout = 30
services = nss, pam, sudo, ssh
# BOUNCE DEV
domains = LOCAL, HOSTOPIA, DOMAIN1, DOMAIN2, DOMAIN3

[nss]
filter_users = 
adm,apache,avahi,bin,daemon,dbus,ecryptfs,ftp,git,games,gopher,haldaemon,halt,hfallback,hdeploy,influxdb,ldap,lp,mail,mailnull,named,news,nfsnobody,nobody,nscd,nslcd,ntp,operator,oprofile,osse

c,postfix,puppet,puppet-dashboard,pulse,pulse-access,radiusd,root,rpc,rpcuser,rtkit,saslauth,sfallback,shutdown,slocate,smmsp,sshd,sync,tcpdump,tss,uucp,vcsa
filter_groups = 
adm,apache,audio,bin,cdrom,cgred,daemon,dbus,dialout,dip,disk,ecryptfs,floppy,fuse,git,hfallback,hdeploy,influxdb,kmem,ldap,lock,lp,mail,mailnull,man,mem,nfsnobody,nobody,nscd,ntp,ossec,oprof

ile,postdrop,postfix,puppet,puppet-dashboard,pulse,pulse-access,root,rpc,rpcuser,rtkit,saslauth,sfallback,slocate,smmsp,sshd,sys,tape,tcpdump,tss,tty,users,utempter,utmp,vcsa,video


[pam]
debug_level = 0
reconnection_retries = 3
offline_credentials_expiration = 2
offline_failed_login_attempts = 3
offline_failed_login_delay = 5
pam_verbosity = 1
pam_pwd_expiration_warning = 21
pam_account_expired_message = Your LDAP password has expired, please 
use selfservice portal to change your LDAP password.


[sudo]
debug_level = 0

[ssh]
# debug_level = 0


[domain/LOCAL]
description = LOCAL Users domain
id_provider = local
enumerate = true
min_id = 500
max_id = 999
default_shell = /bin/bash
base_directory = /home
create_homedir = false
remove_homedir = true
homedir_umask = 077
skel_dir = /etc/skel
mail_dir = /var/spool/mail


All domains have the following options set:

# SECTION: HOSTOPIA
[domain/HOSTOPIA]
min_id = 499
debug_level = 0
cache_credentials = True
entry_cache_timeout = 864000

auth_provider = ldap
id_provider = ldap
access_provider = ldap
chpass_provider = none
sudo_provider = ldap
selinux_provider = none
autofs_provider = none
hostid_provider = none

ldap_use_tokengroups = false

# 
https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/

#ignore_group_members=True

lookup_family_order = ipv4_only

# LDAP Search
ldap_search_base = dc=hostopia,dc=com
ldap_group_search_base = 
ou=groups,o=Hostopia,dc=hostopia,dc=com?subtree?(|(cn=almighties)(cn=security)(cn=systems)(cn=bounce-development)(cn=development-wholesale)(cn=development-retail)(cn=abuse))
ldap_user_search_base = 
ou=users,o=hostopia,dc=hostopia,dc=com?subtree?(|(description=cn=bounce-development,ou=groups,o=Hostopia,dc=hostopia,dc=com)(description=cn=almighties,ou=groups,o=Hostopia,dc=hostopia

,dc=com)(description=cn=security,ou=groups,o=Hostopia,dc=hostopia,dc=com))

# LDAP Custom Schema
ldap_group_member = hMemberDN
ldap_user_member_of = description
# ldap_schema can be set to "rfc2307", which stores group member 
names in the
# "memberuid" attribute, or to "rfc2307bis", which stores group 
member DNs in

# the "member" attribute. If you do not know this value, ask your LDAP
# administrator.
ldap_schema = rfc2307bis

ldap_network_timeout = 3
ldap_id_use_start_tls = False
ldap_tls_reqcert = never
ldap_tls_cacertdir = /etc/openldap/cacerts

# Ldap Servers
ldap_uri = ldaps://SERVER1, ldaps://SERVER2, ldaps://SERVER3
ldap_backup_uri = ldaps://1.1.1.1

ldap_default_authtok_type = obfuscated_password
ldap_default_bind_dn = 
ldap_default_authtok = **

ldap_user_ssh_public_key = sshPublicKey

ldap_pwd_policy = none
ldap_account_expire_policy = shadow
ldap_user_shadow_expire   = shadowExpire
# shadowExpire: days since Jan 1, 1970 that account is disabled: $ 
echo $(($(date --utc --date "$1" +%s)/86400))


ldap_chpass_update_last_change = false

ldap_access_order = filter, expire
ldap_access_filter = 
(&(objectClass=posixAccount)(uidNumber=*)(hAccountInitialSetup=1)(|(description=cn=bounce-development,ou=groups,o=Hostopia,dc=hostopia,dc=com)(descripti

[SSSD-users] Re: id: cannot find name for group ID

[Mario Rossi]

Should I sanitize the logs and send them over ?
Thank you

On 07/23/2018 05:26 PM, Mario Rossi wrote:

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
user:*:11012:1001:User Name:/home/user:/bin/bash

However, a quick lookup against the group:

[user@snoopy ~]$ *getent -s sss group security*
security:*:1001:user

Subsequent id lookup works:

[user@snoopy ~]$ id
uid=11012(user) *gid=1001(security) 
**groups=1001(security)*,10(wheel),1102



Sudo also complains about the user, even after above command succeeds

[user@snoopy ~]$*sudo su -*
*sudo: unknown uid 11012: who are you?*


A few seconds later sudo is no longer confused:

[user@snoopy ~]$*sudo su -*
*LDAP OnePassword for **user**:*
root@snoopy[~]#


SSSD config:

[sssd]
config_file_version = 2
sbus_timeout = 30
services = nss, pam, sudo, ssh
# BOUNCE DEV
domains = LOCAL, HOSTOPIA, DOMAIN1, DOMAIN2, DOMAIN3

[nss]
filter_users = 
adm,apache,avahi,bin,daemon,dbus,ecryptfs,ftp,git,games,gopher,haldaemon,halt,hfallback,hdeploy,influxdb,ldap,lp,mail,mailnull,named,news,nfsnobody,nobody,nscd,nslcd,ntp,operator,oprofile,osse

c,postfix,puppet,puppet-dashboard,pulse,pulse-access,radiusd,root,rpc,rpcuser,rtkit,saslauth,sfallback,shutdown,slocate,smmsp,sshd,sync,tcpdump,tss,uucp,vcsa
filter_groups = 
adm,apache,audio,bin,cdrom,cgred,daemon,dbus,dialout,dip,disk,ecryptfs,floppy,fuse,git,hfallback,hdeploy,influxdb,kmem,ldap,lock,lp,mail,mailnull,man,mem,nfsnobody,nobody,nscd,ntp,ossec,oprof

ile,postdrop,postfix,puppet,puppet-dashboard,pulse,pulse-access,root,rpc,rpcuser,rtkit,saslauth,sfallback,slocate,smmsp,sshd,sys,tape,tcpdump,tss,tty,users,utempter,utmp,vcsa,video


[pam]
debug_level = 0
reconnection_retries = 3
offline_credentials_expiration = 2
offline_failed_login_attempts = 3
offline_failed_login_delay = 5
pam_verbosity = 1
pam_pwd_expiration_warning = 21
pam_account_expired_message = Your LDAP password has expired, please 
use selfservice portal to change your LDAP password.


[sudo]
debug_level = 0

[ssh]
# debug_level = 0


[domain/LOCAL]
description = LOCAL Users domain
id_provider = local
enumerate = true
min_id = 500
max_id = 999
default_shell = /bin/bash
base_directory = /home
create_homedir = false
remove_homedir = true
homedir_umask = 077
skel_dir = /etc/skel
mail_dir = /var/spool/mail


All domains have the following options set:

# SECTION: HOSTOPIA
[domain/HOSTOPIA]
min_id = 499
debug_level = 0
cache_credentials = True
entry_cache_timeout = 864000

auth_provider = ldap
id_provider = ldap
access_provider = ldap
chpass_provider = none
sudo_provider = ldap
selinux_provider = none
autofs_provider = none
hostid_provider = none

ldap_use_tokengroups = false

# 
https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/

#ignore_group_members=True

lookup_family_order = ipv4_only

# LDAP Search
ldap_search_base = dc=hostopia,dc=com
ldap_group_search_base = 
ou=groups,o=Hostopia,dc=hostopia,dc=com?subtree?(|(cn=almighties)(cn=security)(cn=systems)(cn=bounce-development)(cn=development-wholesale)(cn=development-retail)(cn=abuse))
ldap_user_search_base = 
ou=users,o=hostopia,dc=hostopia,dc=com?subtree?(|(description=cn=bounce-development,ou=groups,o=Hostopia,dc=hostopia,dc=com)(description=cn=almighties,ou=groups,o=Hostopia,dc=hostopia

,dc=com)(description=cn=security,ou=groups,o=Hostopia,dc=hostopia,dc=com))

# LDAP Custom Schema
ldap_group_member = hMemberDN
ldap_user_member_of = description
# ldap_schema can be set to "rfc2307", which stores group member names 
in the
# "memberuid" attribute, or to "rfc2307bis", which stores group member 
DNs in

# the "member" attribute. If you do not know this value, ask your LDAP
# administrator.
ldap_schema = rfc2307bis

ldap_network_timeout = 3
ldap_id_use_start_tls = False
ldap_tls_reqcert = never
ldap_tls_cacertdir = /etc/openldap/cacerts

# Ldap Servers
ldap_uri = ldaps://SERVER1, ldaps://SERVER2, ldaps://SERVER3
ldap_backup_uri = ldaps://1.1.1.1

ldap_default_authtok_type = obfuscated_password
ldap_default_bind_dn = 
ldap_default_authtok = **

ldap_user_ssh_public_key = sshPublicKey

ldap_pwd_policy = none
ldap_account_expire_policy = shadow
ldap_user_shadow_expire   = shadowExpire
# shadowExpire: days since Jan 1, 1970 that account is disabled: $ 
echo $(($(date --utc --date "$1" +%s)/86400))


ldap_chpass_update_last_change = false

ldap_access_order = filter, expire
ldap_access_filter = 
(&(objectClass=posixAccount)(uidNumber=*)(hAccountInitialSetup=1)(|(description=cn=bounce-development,ou=groups,o=Hostopia,dc=hostopia,dc=com)(description=cn=almighties,ou=groups,o=Hosto

pia,dc=hostopia,dc=com)(description=cn=secur

[SSSD-users] id: cannot find name for group ID

[Mario Rossi]

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
user:*:11012:1001:User Name:/home/user:/bin/bash

However, a quick lookup against the group:

[user@snoopy ~]$ *getent -s sss group security*
security:*:1001:user

Subsequent id lookup works:

[user@snoopy ~]$ id
uid=11012(user) *gid=1001(security) 
**groups=1001(security)*,10(wheel),1102



Sudo also complains about the user, even after above command succeeds

[user@snoopy ~]$*sudo su -*
*sudo: unknown uid 11012: who are you?*


A few seconds later sudo is no longer confused:

[user@snoopy ~]$*sudo su -*
*LDAP OnePassword for **user**:*
root@snoopy[~]#


SSSD config:

[sssd]
config_file_version = 2
sbus_timeout = 30
services = nss, pam, sudo, ssh
# BOUNCE DEV
domains = LOCAL, HOSTOPIA, DOMAIN1, DOMAIN2, DOMAIN3

[nss]
filter_users = 
adm,apache,avahi,bin,daemon,dbus,ecryptfs,ftp,git,games,gopher,haldaemon,halt,hfallback,hdeploy,influxdb,ldap,lp,mail,mailnull,named,news,nfsnobody,nobody,nscd,nslcd,ntp,operator,oprofile,osse

c,postfix,puppet,puppet-dashboard,pulse,pulse-access,radiusd,root,rpc,rpcuser,rtkit,saslauth,sfallback,shutdown,slocate,smmsp,sshd,sync,tcpdump,tss,uucp,vcsa
filter_groups = 
adm,apache,audio,bin,cdrom,cgred,daemon,dbus,dialout,dip,disk,ecryptfs,floppy,fuse,git,hfallback,hdeploy,influxdb,kmem,ldap,lock,lp,mail,mailnull,man,mem,nfsnobody,nobody,nscd,ntp,ossec,oprof

ile,postdrop,postfix,puppet,puppet-dashboard,pulse,pulse-access,root,rpc,rpcuser,rtkit,saslauth,sfallback,slocate,smmsp,sshd,sys,tape,tcpdump,tss,tty,users,utempter,utmp,vcsa,video


[pam]
debug_level = 0
reconnection_retries = 3
offline_credentials_expiration = 2
offline_failed_login_attempts = 3
offline_failed_login_delay = 5
pam_verbosity = 1
pam_pwd_expiration_warning = 21
pam_account_expired_message = Your LDAP password has expired, please use 
selfservice portal to change your LDAP password.


[sudo]
debug_level = 0

[ssh]
# debug_level = 0


[domain/LOCAL]
description = LOCAL Users domain
id_provider = local
enumerate = true
min_id = 500
max_id = 999
default_shell = /bin/bash
base_directory = /home
create_homedir = false
remove_homedir = true
homedir_umask = 077
skel_dir = /etc/skel
mail_dir = /var/spool/mail


All domains have the following options set:

# SECTION: HOSTOPIA
[domain/HOSTOPIA]
min_id = 499
debug_level = 0
cache_credentials = True
entry_cache_timeout = 864000

auth_provider = ldap
id_provider = ldap
access_provider = ldap
chpass_provider = none
sudo_provider = ldap
selinux_provider = none
autofs_provider = none
hostid_provider = none

ldap_use_tokengroups = false

# 
https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/

#ignore_group_members=True

lookup_family_order = ipv4_only

# LDAP Search
ldap_search_base = dc=hostopia,dc=com
ldap_group_search_base = 
ou=groups,o=Hostopia,dc=hostopia,dc=com?subtree?(|(cn=almighties)(cn=security)(cn=systems)(cn=bounce-development)(cn=development-wholesale)(cn=development-retail)(cn=abuse))
ldap_user_search_base = 
ou=users,o=hostopia,dc=hostopia,dc=com?subtree?(|(description=cn=bounce-development,ou=groups,o=Hostopia,dc=hostopia,dc=com)(description=cn=almighties,ou=groups,o=Hostopia,dc=hostopia

,dc=com)(description=cn=security,ou=groups,o=Hostopia,dc=hostopia,dc=com))

# LDAP Custom Schema
ldap_group_member = hMemberDN
ldap_user_member_of = description
# ldap_schema can be set to "rfc2307", which stores group member names 
in the
# "memberuid" attribute, or to "rfc2307bis", which stores group member 
DNs in

# the "member" attribute. If you do not know this value, ask your LDAP
# administrator.
ldap_schema = rfc2307bis

ldap_network_timeout = 3
ldap_id_use_start_tls = False
ldap_tls_reqcert = never
ldap_tls_cacertdir = /etc/openldap/cacerts

# Ldap Servers
ldap_uri = ldaps://SERVER1, ldaps://SERVER2, ldaps://SERVER3
ldap_backup_uri = ldaps://1.1.1.1

ldap_default_authtok_type = obfuscated_password
ldap_default_bind_dn = 
ldap_default_authtok = **

ldap_user_ssh_public_key = sshPublicKey

ldap_pwd_policy = none
ldap_account_expire_policy = shadow
ldap_user_shadow_expire   = shadowExpire
# shadowExpire: days since Jan 1, 1970 that account is disabled: $ echo 
$(($(date --utc --date "$1" +%s)/86400))


ldap_chpass_update_last_change = false

ldap_access_order = filter, expire
ldap_access_filter = 
(&(objectClass=posixAccount)(uidNumber=*)(hAccountInitialSetup=1)(|(description=cn=bounce-development,ou=groups,o=Hostopia,dc=hostopia,dc=com)(description=cn=almighties,ou=groups,o=Hosto

pia,dc=hostopia,dc=com)(description=cn=security,ou=groups,o=Hostopia,dc=hostopia,dc=com)))

# SUDO
ldap_sudo_search_base = ou=sudoers,o=Hostopia,dc=hostopia,dc=com
ldap_sudo_full_refresh_interval = 86400

[SSSD-users] Re: Missing group memberships with sssd (when using tokengroups)

[Mario Rossi]

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 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 ( yes, I use both ).


[root@snoopy ~]$ rpm -q sssd
sssd-1.16.0-19.el7_5.5.x86_64

root@snoopy[/etc/sssd]# service sssd stop; rm -f /var/lib/sss/db/*; 
service sssd start

Redirecting to /bin/systemctl stop sssd.service
Redirecting to /bin/systemctl start sssd.service

root@snoopy[/etc/sssd]# id ezaporozh...@hostopia.com
uid=11158(ezaporozhets)*gid=1004* groups=*1004*,1102


root@snoopy[/etc/sssd]# *getent -s sss group 
development-wholes...@hostopia.com*

development-wholesale:*:1004:ezaporozhets,alyubyanitskiy

root@snoopy[/etc/sssd]# id ezaporozh...@hostopia.com
uid=11158(ezaporozhets)*gid=1004(development-wholesale) 
**groups=1004(development-wholesale),1102*


I tried setting ldap_use_tokengroups = false at domain level, however 
still seeing the issue. I use ldap provider.


Thank you

On 07/23/2018 04:13 AM, Jakub Hrozek wrote:

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 
ldap_use_tokengroups = True.

Logs are at this URL:
https://www.dropbox.com/sh/l37pj104qkrqxfa/AACuKgaQjWZ4MVr1NdEogbcMa?dl=0

I have included the realmd.conf, sssd.conf and krb5.conf as well.

Here's (incorrect) result back from sssd with ldap_use_tokengroups = True

[root@spikerealmd02 sssd]# id admpatrick_wheeler
uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) 
groups=2604370(admpatrick_wheeler),1010(amerunixusers)


Thank you, now the logs are more helpful. What I see is repetition of “cant 
find domain for $SID”. And I believe this is because the subdomains provider is 
disabled, because (quite confusingly) the subdomains provider is also 
responsible for fetching information about the joined domain, like its SID or 
the NetBIOS name.

So I think there are three options:
1) add ad_enabled_domains=$self to each of the domains, e.g. add 
ad_enabled_domains=amer.dell.com to the amer.dell.com domain. This should make 
sssd fetch info about that domain only. I know you wrote earlier that this gave 
you some other headaches, but if it does, then there’s another bug..
2) try to help sssd by setting the domain SID manually with the 
ldap_idmap_default_domain_sid option
3) just use tokengroups=false as a workaround.


Here is correct result back when ldap_use_tokengropus = False:

[root@spikerealmd02 sssd]# id admpatrick_wheeler
uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) 
groups=2604370(admpatrick_wheeler),2283577(delta_bd_create_emea),2283643(gebs_read_prd),2283611(xxgl0370_prod),2283578(delta_bd_create),2283256(infa_developer),2283623(xxgl0363_prod),2283615(xxgl0503_prod),2283607(xxpa2891_prod),2283869(cowcprodsupport),1010(amerunixusers),1156(gbl_server_support),2284161(amerserveradministrator),2283573(dfs_gil_sit_auth),1033(amer_server_mgmt),1003(amerlinuxsup)

this is sssd version 1.16.0

Spike




Thanks, this is more helpful

On Thu, Jul 19, 2018 at 4:15 AM Jakub Hrozek  wrote:



On 13 Jul 2018, at 17:40, Spike White  wrote:

Jakub,

Thank you to answering so promptly.

We are currently testing this in a lab before full deployment, so I have some 
degree of time before we deploy sssd in a bigger context.  If you would prefer 
for me to work with you directly off-line, please advise.  As an example, the 
attached sssd_amer.dell.com.log file was originally 40 MB.  (I presume because 
of debugging level).  Out of respect for others on the mailing list, I severely 
trimmed the log file to only the lines of interest (I hope).  But it's entirely 
possible I may have over-trimmed.


I’m afraid so, because the logs say:

(Fri Jul 13 09:25:43 2018) [sssd[be[amer.dell.com]]] [sdap_parse_range] 
(0x2000): No sub-attributes for [tokenGroups]
….

and I’m really interested in this part :-)

(Fri Jul 13 09:25:43 2018) [sssd[be[amer.dell.com]]] 
[sdap_ad_tokengroups_update_members] (0x1000): Updating memberships for 
[admpatrick_whee...@amer.dell.com]
...
(Fri Jul 13 09:25:48 2018) [sssd[be[amer.dell.com]]] 
[sdap_asq_search_parse_entry] (0x2000): Matched objectclass [user] on DN 
[CN=AdmPatrick_Wheeler,OU=AdmAccounts,DC=amer,DC=dell,DC=com], will use 
associated map



You asked:
 Can you send logs for a single lookup of "id username" with tokengroups 
enabled?

Attached are the logs.  ss

[SSSD-users] Re: Missing group memberships with sssd (when using tokengroups)

[Mario Rossi]

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 ( yes, I use both ).


[root@snoopy ~]$ rpm -q sssd
sssd-1.16.0-19.el7_5.5.x86_64

root@snoopy[/etc/sssd]# service sssd stop; rm -f /var/lib/sss/db/*; 
service sssd start

Redirecting to /bin/systemctl stop sssd.service
Redirecting to /bin/systemctl start sssd.service

root@snoopy[/etc/sssd]# id ezaporozh...@hostopia.com
uid=11158(ezaporozhets)*gid=1004* groups=*1004*,1102


root@snoopy[/etc/sssd]# *getent -s sss group 
development-wholes...@hostopia.com*

development-wholesale:*:1004:ezaporozhets,alyubyanitskiy

root@snoopy[/etc/sssd]# id ezaporozh...@hostopia.com
uid=11158(ezaporozhets)*gid=1004(development-wholesale) 
**groups=1004(development-wholesale),1102*


I tried setting ldap_use_tokengroups = false at domain level, however 
still seeing the issue. I use ldap provider.


Thank you

On 07/23/2018 04:13 AM, Jakub Hrozek wrote:



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 
ldap_use_tokengroups = True.

Logs are at this URL:
https://www.dropbox.com/sh/l37pj104qkrqxfa/AACuKgaQjWZ4MVr1NdEogbcMa?dl=0

I have included the realmd.conf, sssd.conf and krb5.conf as well.

Here's (incorrect) result back from sssd with ldap_use_tokengroups = True

[root@spikerealmd02 sssd]# id admpatrick_wheeler
uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) 
groups=2604370(admpatrick_wheeler),1010(amerunixusers)


Thank you, now the logs are more helpful. What I see is repetition of “cant 
find domain for $SID”. And I believe this is because the subdomains provider is 
disabled, because (quite confusingly) the subdomains provider is also 
responsible for fetching information about the joined domain, like its SID or 
the NetBIOS name.

So I think there are three options:
1) add ad_enabled_domains=$self to each of the domains, e.g. add 
ad_enabled_domains=amer.dell.com to the amer.dell.com domain. This should make 
sssd fetch info about that domain only. I know you wrote earlier that this gave 
you some other headaches, but if it does, then there’s another bug..
2) try to help sssd by setting the domain SID manually with the 
ldap_idmap_default_domain_sid option
3) just use tokengroups=false as a workaround.


Here is correct result back when ldap_use_tokengropus = False:

[root@spikerealmd02 sssd]# id admpatrick_wheeler
uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) 
groups=2604370(admpatrick_wheeler),2283577(delta_bd_create_emea),2283643(gebs_read_prd),2283611(xxgl0370_prod),2283578(delta_bd_create),2283256(infa_developer),2283623(xxgl0363_prod),2283615(xxgl0503_prod),2283607(xxpa2891_prod),2283869(cowcprodsupport),1010(amerunixusers),1156(gbl_server_support),2284161(amerserveradministrator),2283573(dfs_gil_sit_auth),1033(amer_server_mgmt),1003(amerlinuxsup)

this is sssd version 1.16.0

Spike




Thanks, this is more helpful

On Thu, Jul 19, 2018 at 4:15 AM Jakub Hrozek  wrote:



On 13 Jul 2018, at 17:40, Spike White  wrote:

Jakub,

Thank you to answering so promptly.

We are currently testing this in a lab before full deployment, so I have some 
degree of time before we deploy sssd in a bigger context.  If you would prefer 
for me to work with you directly off-line, please advise.  As an example, the 
attached sssd_amer.dell.com.log file was originally 40 MB.  (I presume because 
of debugging level).  Out of respect for others on the mailing list, I severely 
trimmed the log file to only the lines of interest (I hope).  But it's entirely 
possible I may have over-trimmed.


I’m afraid so, because the logs say:

(Fri Jul 13 09:25:43 2018) [sssd[be[amer.dell.com]]] [sdap_parse_range] 
(0x2000): No sub-attributes for [tokenGroups]
….

and I’m really interested in this part :-)

(Fri Jul 13 09:25:43 2018) [sssd[be[amer.dell.com]]] 
[sdap_ad_tokengroups_update_members] (0x1000): Updating memberships for 
[admpatrick_whee...@amer.dell.com]
...
(Fri Jul 13 09:25:48 2018) [sssd[be[amer.dell.com]]] 
[sdap_asq_search_parse_entry] (0x2000): Matched objectclass [user] on DN 
[CN=AdmPatrick_Wheeler,OU=AdmAccounts,DC=amer,DC=dell,DC=com], will use 
associated map



You asked:
 Can you send logs for a single lookup of "id username" with tokengroups 
enabled?

Attached are the logs.  sssd_amer.dell.com.log and sssd_nss.log, for this 
lookup:

[root@spikerealmd02 sssd]# id admpatrick_wheeler
uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) 
groups=2604370(admpatrick_wheeler),1010(amerunixusers)

This is with ldap_use_tokengroups = True, so the 

[SSSD-users] Re: sssd with OTP does not work in all cases.

[Mario Rossi]

There are a couple of things to check, older versions of sssd package 
sudo in a separate rpm and not all versions of sudo integrate with sssd, 
upgrade to the latest sudo package that your distro supports, just in case.


If sssd.conf has the proper refereces to sudo e.g.

services = nss, pam, sudo, ssh
.
[sudo]
# debug_level=9

[domain/XYZ]

sudo_provider = ldap
ldap_sudo_search_base = ou=sudoers,dc=example,dc=net
ldap_sudo_full_refresh_interval = 86400
ldap_sudo_smart_refresh_interval = 3600

Additional troubleshooting steps:
Flush sssd cache just in case with  sss_cache -E , as root on the 
server, su to the user, do id -G myuser, id myuser, after which try 
logging in with ssh as the user and use sudo. List all sudo rules, as 
root, with: sudo -U myuser -l


I almost forgot, /etc/nsswitch.conf must have a sudoers line to point to 
sssd:

$ egrep sudo /etc/nsswitch.conf
sudoers:    files sss


If you still see issues , I would recommend turning debugging on for 
sssd, sudo, looking through openldap logs for queries done by sssd. In 
addition, the next link might also help.


https://jhrozek.livejournal.com/2065.html

Let us know how it goes. I assumed your openldap is loading the sudo 
schema and you have configured at least one rule in openldap for sudo. 
In my environment I modified the sudo password prompt ( see option 
passprompt) , that way I can distinguish between a non-ldap sudo and 
sssd-enabled sudo :)


Let us know how it goes ...


On 11/02/2017 03:13 PM, Asif Iqbal wrote:



On Fri, Oct 27, 2017 at 10:53 AM, Mario Rossi <mro...@hostopia.com 
<mailto:mro...@hostopia.com>> wrote:


What OS are you using ? I am using Centos 6  with RSA ( fixed
password + PIN ) + sssd/ldap auth , so yes, that does give you
BOTH prompts, one for RSA and one for LDAP. If you need to ONLY
use RSA w account lookup from sssd/ldap, then you have to comment
out the auth line related to system-auth-ac in  /etc/pam.d/sshd.
You also have to be careful what umask are you using, make sure
file perms is set to 0644 . Also if you run authconfig to manage
/etc/pam.d, your files may be overwritten, so you may need to
import custom setting into your deployment system i.e.
puppet/ansible.

Have you set *ChallengeResponseAuthentication* to yes in
/etc/ssh/sshd_config ?

Example of a system that uses RSA for sshd , so you get *only one*
password prompt:

$ cat /etc/pam.d/sshd
#%PAM-1.0
auth   required pam_securid.so reserve
*#auth   include  system-auth-ac*
account    required pam_nologin.so
account    include  system-auth-ac
password   include  system-auth-ac
session    optional pam_keyinit.so force revoke
session    include  system-auth-ac
session    required pam_loginuid.so

$ cat */etc/pam.d/system-auth-ac *
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth    required pam_env.so
auth    sufficient    pam_unix.so nullok try_first_pass
auth    requisite pam_succeed_if.so uid >= 500 quiet
auth    sufficient    pam_sss.so use_first_pass
auth    required  pam_deny.so

account required  pam_unix.so
account sufficient    pam_localuser.so
account sufficient    pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required  pam_permit.so

password    requisite pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so sha512 shadow nullok
try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    required  pam_deny.so

session optional  pam_keyinit.so revoke
session required  pam_limits.so
session optional  pam_mkhomedir.so
session [success=1 default=ignore] pam_succeed_if.so service
in crond quiet use_uid
session required  pam_unix.so
session optional  pam_sss.so


I got it working with your config.

I can ssh with OTP and it does check my LDAP attributes as well.

I have auth_provider = ldap now as well so I can sudo auth based on LDAP.

Howerver sudo is failing and here is my pam.d/sudo looks like

[root@localhost vagrant]# cat /etc/pam.d/sudo
#%PAM-1.0
auth       include      system-auth-ac
account    include      system-auth-ac
password   include      system-auth-ac
session    optional     pam_keyinit.so revoke
session    required     pam_limits.so

$ sudo -s
[sudo] password for iqbala:
sudo: account validation failure, is your account locked?

It is not locked in LDAP and I checked.

Any suggestion what is going wrong there? I am using your system-auth-ac







On 10/27/2017 10:27 AM, Asif Iqbal wrote:

This setup also failed miserably where pam.d/sshd first two lines
like below

a

[SSSD-users] Re: Change LDAP-Filter for SSSD

[Mario Rossi]

If using own objectclass, I would think you will use custom attributes ?

ldap_group_member = *hMemberDN*
ldap_user_member_of = *description*

Thanks

On 11/02/2017 08:15 AM, Stefan Kania wrote:

Hello,

I would like to change the search-filter for sssd because I created my
own Group-Objectclass, but if I do a "getent group" I will not see my
own group.
My sssd.conf looks like this:
--
[sssd]
config_file_version = 2
services = nss, pam
domains = LDAP

[domain/LDAP]
ldap_schema=rfc2307
ldap_uri = ldap://ldapserver.example.net:389
ldap_search_base=dc=example,dc=net
ldap_default_bind_dn=uid=sssd-user,ou=users,dc=example,dc=net
ldap_default_authtok=geheim
id_provider=ldap
auth_provider=ldap
chpass_provider = ldap
ldap_chpass_uri = ldap://ldapmaster.example.net:389
cache_credentials = True
enumerate = true
ldap_tls_cacertdir = /etc/ssl/zertifikate/demoCA
ldap_tls_cacert = /etc/ssl/zertifikate/demoCA/cacert.pem
--

Everytime I do a "getent group" I see the following lines inside the log:
--
Nov 02 13:10:47 ldapserver slapd[2007]: conn=1044 op=1 BIND
dn="uid=sssd-user,ou=users,dc=example,dc=net" mech=SIMPLE ssf=0
Nov 02 13:10:47 ldapserver slapd[2007]: conn=1044 op=1 RESULT tag=97
err=0 text=

Nov 02 13:10:47 ldapserver slapd[2007]: conn=1044 op=2 SRCH
base="dc=example,dc=net" scope=2 deref=0
filter="(&(objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*))"
---
Is it possible to change the Filter:
(&(objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*))

If "yes" how can I do this? I read to many howtos but I could not find a
solution.

Thanks for your help

Stefan
--



___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: sssd with OTP does not work in all cases.

[Mario Rossi]

What OS are you using ? I am using Centos 6 with RSA ( fixed password + 
PIN ) + sssd/ldap auth , so yes, that does give you BOTH prompts, one 
for RSA and one for LDAP. If you need to ONLY use RSA w account lookup 
from sssd/ldap, then you have to comment out the auth line related to 
system-auth-ac in /etc/pam.d/sshd. You also have to be careful what 
umask are you using, make sure file perms is set to 0644 . Also if you 
run authconfig to manage /etc/pam.d, your files may be overwritten, so 
you may need to import custom setting into your deployment system i.e. 
puppet/ansible.


Have you set *ChallengeResponseAuthentication* to yes in 
/etc/ssh/sshd_config ?


Example of a system that uses RSA for sshd , so you get *only one* 
password prompt:


$ cat /etc/pam.d/sshd
#%PAM-1.0
auth   required pam_securid.so reserve
*#auth   include  system-auth-ac*
account    required pam_nologin.so
account    include  system-auth-ac
password   include  system-auth-ac
session    optional pam_keyinit.so force revoke
session    include  system-auth-ac
session    required pam_loginuid.so

$ cat */etc/pam.d/system-auth-ac *
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth    required  pam_env.so
auth    sufficient    pam_unix.so nullok try_first_pass
auth    requisite pam_succeed_if.so uid >= 500 quiet
auth    sufficient    pam_sss.so use_first_pass
auth    required  pam_deny.so

account required  pam_unix.so
account sufficient    pam_localuser.so
account sufficient    pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required  pam_permit.so

password    requisite pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so sha512 shadow nullok 
try_first_pass use_authtok

password    sufficient    pam_sss.so use_authtok
password    required  pam_deny.so

session optional  pam_keyinit.so revoke
session required  pam_limits.so
session optional  pam_mkhomedir.so
session [success=1 default=ignore] pam_succeed_if.so service in 
crond quiet use_uid

session required  pam_unix.so
session optional  pam_sss.so

On 10/27/2017 10:27 AM, Asif Iqbal wrote:
This setup also failed miserably where pam.d/sshd first two lines like 
below


auth       required     pam_securid.so
auth       include      system-auth-ac_new

And using your pam.d/system-auth-ac_new

So it does give you the right prompt 'Enter SMS Token:' when just put 
PIN at first login prompt. But after putting SMS token on the next prompt
it goes back to Password: prompt again. Even worse is now it does not 
even work with giving both PIN and TokenCode at the first prompt either.


Any other suggestion? Does anyone work with SSS and OTP at all?

Seems like I should just not use sss since OTP is a *must* requirement.





On Thu, Oct 26, 2017 at 8:54 PM, Mario Rossi <mro...@hostopia.com 
<mailto:mro...@hostopia.com>> wrote:



My 2c, having two 'Password:' prompts ( RSA + sssd ) will confuse
your users, the easiest would be to configure sd_pam.conf to use a
different prompt for RSA.

$ egrep ^AUTH /etc/sd_pam.conf
AUTH_CHALLENGE_USERNAME_STR=Enter USERNAME :
AUTH_CHALLENGE_RESERVE_REQUEST_STR=Please enter System Password
for root :
AUTH_CHALLENGE_PASSCODE_STR=Enter SecureKey :
AUTH_CHALLENGE_PASSWORD_STR=Enter your SecureKey :

Now back to your question, I believe you need to define a new
system-auth file to be used, in my case
system-auth-ac_new with custom pam config. This is a working rsa +
sssd (openldap ) setup, I am not sure about proxy as I haven't
used it before.


$ cat /etc/pam.d/sshd
#%PAM-1.0
auth   required pam_securid.so reserve
auth   include  system-auth-ac_new
account    required pam_nologin.so
account    include  system-auth-ac_new
password   include  system-auth-ac_new
session    optional pam_keyinit.so force revoke
session    include  system-auth-ac_new
session    required pam_loginuid.so

$ cat /etc/pam.d/system-auth-ac_new
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth    sufficient    pam_sss.so
auth    required  pam_env.so
auth    sufficient    pam_unix.so nullok try_first_pass
auth    requisite pam_succeed_if.so uid >= 500 quiet
auth    required  pam_deny.so

account [default=bad success=ok user_unknown=ignore] pam_sss.so
#account required  pam_access.so
account required  pam_unix.so broken_shadow
account sufficient    pam_localuser.so
account sufficient    pam_succeed_if.so uid < 500 quiet
account required  pam

[SSSD-users] Re: sssd with OTP does not work in all cases.

[Mario Rossi]

My 2c, having two 'Password:' prompts ( RSA + sssd ) will confuse your 
users, the easiest would be to configure sd_pam.conf to use a different 
prompt for RSA.


$ egrep ^AUTH /etc/sd_pam.conf
AUTH_CHALLENGE_USERNAME_STR=Enter USERNAME :
AUTH_CHALLENGE_RESERVE_REQUEST_STR=Please enter System Password for root :
AUTH_CHALLENGE_PASSCODE_STR=Enter SecureKey :
AUTH_CHALLENGE_PASSWORD_STR=Enter your SecureKey :

Now back to your question, I believe you need to define a new 
system-auth file to be used, in my case
system-auth-ac_new with custom pam config. This is a working rsa + sssd 
(openldap ) setup, I am not sure about proxy as I haven't used it before.



$ cat /etc/pam.d/sshd
#%PAM-1.0
auth   required pam_securid.so reserve
auth   include  system-auth-ac_new
account    required pam_nologin.so
account    include  system-auth-ac_new
password   include  system-auth-ac_new
session    optional pam_keyinit.so force revoke
session    include  system-auth-ac_new
session    required pam_loginuid.so

$ cat /etc/pam.d/system-auth-ac_new
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth    sufficient    pam_sss.so
auth    required  pam_env.so
auth    sufficient    pam_unix.so nullok try_first_pass
auth    requisite pam_succeed_if.so uid >= 500 quiet
auth    required  pam_deny.so

account [default=bad success=ok user_unknown=ignore] pam_sss.so
#account required  pam_access.so
account required  pam_unix.so broken_shadow
account sufficient    pam_localuser.so
account sufficient    pam_succeed_if.so uid < 500 quiet
account required  pam_permit.so

password    sufficient    pam_sss.so use_authtok
password    requisite pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so sha512 shadow nullok 
try_first_pass use_authtok

password    required  pam_deny.so

session optional  pam_sss.so
session optional  pam_keyinit.so revoke
session required  pam_limits.so
session optional  pam_mkhomedir.so
session [success=1 default=ignore] pam_succeed_if.so service in 
crond quiet use_uid

session required  pam_unix.so

On 10/26/2017 07:34 PM, Asif Iqbal wrote:

With pam_securid.so

I can on /etc/pam.d/sshd

   auth sufficient pam_securid.so

and at ssh login, I just put PIN at Password: prompt and then I get 
Enter SMS Token: prompt and I can then put the

tokencode and I can ssh into the server fine.

If I do the same with pam_sss.so it keeps asking for Password: and 
never changes the prompt to Enter SMS Token: and ssh fails badly.
At this second Password: prompt I tried with just tokencode (at 
18:45:34 in log below) or PIN and tokencode (at 18:47:55). Neither let

me in and failed eventually.

I think it is because pam_sss -> proxy -> securid -> pam_securd is 
failing to handle PAM conversation?


Is there a way to fix that to so pam_sss to behave the right way and 
let authenticate in two steps with PIN and then TokenCode on next step?


Also without this PAM conversation, when the PIN expires it will not 
let you update it. With simple pam.d/sshd and auth sufficient 
pam_securid.so

that works very well as well.

I have sssd.conf setup like this
   auth_server = proxy
   proxy_target_pam = securid

And in pam.d/securid file
  auth sufficient pam_securid.so

Here are some log http://dpaste.com/2HD27XH.txt where
   I tried with PIN at first Password: prompt and then TokenCode at 
second Password: prompt at 18:45:34 and failed to login

And
   I tried with PIN at first Password: prompt and then PIN and 
TokenCode at second Password: prompt at 18:47:55 and failed to login


I tried with SElinux off and on and same result

If I put PIN and TokenCode at the first Password: prompt, login works 
fine . I did not put any log for that here.


Any suggestion how to fix pam_sss for OTP?

Thanks!







--
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?



___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: Does anyone use id_provider=local ?

[Mario Rossi]

In our environment, regular users authenticate via sssd/ldap, and 
emergency user(s) via PAM if/when sssd + RSA securid fails. Still 
running sssd 1.14.2 on el6.


Thanks

On 10/16/2017 11:04 AM, hedr...@rutgers.edu wrote:

On certain servers I want IPA authentication but the local user/group database. 
With sssd 1.14, I could specify pam as the only service and put files in 
/etc/nsswitch.conf. With sssd 1.15, I get extra groups with that setting. I had 
to set id_provider=none, which is undocumented. I'd be happy to see 
id_provider=files for this situation, though id_provider=none with nsswitch 
seems to do what I need.

I do have a user with a static password, for cases where services are down. 
That can be done in pam, by having pam_unix as well as pam_sss. It would be 
interesting to have sssd handle this kind of mixed case, but it seems like this 
is what pam is for.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org



___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: i have no name

[Mario Rossi]

Hi Thomas,

We run into a similar issue when we used ns(l)cd and kerberos, from time 
to time we saw the message after logging in via ssh. Since we migrated 
off that solution to sssd+openldap we were not able to reproduce it and 
things are stable.


Thank you,
Mario

On 06/19/2017 04:50 PM, Thomas Beaudry wrote:


Hi guys,


i am running into an issue in which my users lose their name 
momentarily.  I have tried disabling reverse dns, and I have a cron 
job that restarts sssd every hour as well as checking the id of each 
username to keep the usernames fresh.  Is there something else I can 
do, or a cache I can enable so it doesn't need to recheck the username 
after you log in  (i know i have been told that sssd cache's 
everything, so I don't understand, why I would lose the username) ?



thanks,

Thomas



___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] el6 1.15.1 diff from 1.14.2 cannot use 2FA

[Mario Rossi]

Hi,

I pulled the unofficial 1.15.1 el6 sssd and installed it today on a host 
where RSA securid is used ( RSA + openldap) . I am trying to log in to 
the server and I am getting ( please note pam_unix fails but that's fine 
as we use ldap ) :


Mar  9 09:17:38 barni sshd[7597]: error: PAM: Authentication failure for 
abcd from X.Y.86.223
Mar  9 09:17:38 barni sshd[7597]: Connection closed by X.Y.86.223 port 
40924 [preauth]
Mar  9 09:18:04 barni sshd[8012]: pam_sss(sshd:auth): authentication 
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=X.Y.86.223 user=abcd
Mar  9 09:18:04 barni sshd[8012]: pam_sss(*sshd:auth*): received for 
user abcd: *7 (Authentication failure)*
Mar  9 09:18:04 barni sshd[8012]: pam_unix(sshd:auth): authentication 
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=X.Y.86.223  user=abcd



I have reverted to 1.14.2 and it magically works :) Is there any 
functionality changed from 1.15.1 to 1.14.2 before I start enabling 
debugging and go through the logs ? The only service needing 2FA is sshd 
so I use a separate system-auth-ac file. With 1.15.1 I get propted for 
2FA each time so it does not go to LDAP password:


*1.14.2:*
[gvasiliu@localhost Downloads]$ ssh -q barni
Enter SecureKey:
*Password: *

*1.15.1:*
[gvasiliu@localhost Downloads]$ ssh -q barni
Enter SecureKey:
Enter SecureKey:

https://fedorahosted.org/sssd/wiki/Releases/Notes-1.15.0
https://docs.pagure.org/SSSD.sssd/users/relnotes/notes_1_15_1.html#

Could this be related to https://pagure.io/SSSD/sssd/issue/2984 ?

root@barni[*/etc/pam.d*]# cat *sshd*
#%PAM-1.0
auth   required pam_securid.so reserve
auth   include  system-auth-ac_new
accountrequired pam_nologin.so
accountinclude  system-auth-ac_new
password   include  system-auth-ac_new
sessionoptional pam_keyinit.so force revoke
sessioninclude  system-auth-ac_new
sessionrequired pam_loginuid.so

root@barni[*/etc/pam.d*]# cat *system-auth-ac_new*
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
authsufficientpam_sss.so
authrequired  pam_env.so
authsufficientpam_unix.so nullok try_first_pass
authrequisite pam_succeed_if.so uid >= 500 quiet
authrequired  pam_deny.so

account [default=bad success=ok user_unknown=ignore] pam_sss.so
#account required  pam_access.so
account required  pam_unix.so broken_shadow
account sufficientpam_localuser.so
account sufficientpam_succeed_if.so uid < 500 quiet
account required  pam_permit.so


passwordsufficientpam_sss.so use_authtok
passwordrequisite pam_cracklib.so try_first_pass retry=3 type=
passwordsufficientpam_unix.so sha512 shadow nullok 
try_first_pass use_authtok

passwordrequired  pam_deny.so

session optional  pam_sss.so
session optional  pam_keyinit.so revoke
session required  pam_limits.so
session optional  pam_mkhomedir.so
session [success=1 default=ignore] pam_succeed_if.so service in 
crond quiet use_uid

session required  pam_unix.so

Thank you

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: Does anyone use id_provider=local ?

[Mario Rossi]

Jakub,

For my production servers I enabled local provider on the customer 
facing servers. I have configured an emergency user that will not be 
shown in /etc/passwd . In a hosting environment anyone can get a a 
domain for a just a few $$ and this exposes passwd file. If I add the 
account to /etc/passwd it could be bruteforced as most brute-forcing 
scripts will reference the file. However if I add it via sss_* tools , 
the account is invisible to them.


I've read the wiki page and I understood the need for replacing it. If 
id_provider=local will be removed I can live without it :)


Thanks
Mario


On 02/10/2017 04:18 AM, Jakub Hrozek wrote:

Hi,

are there any SSSD users who actively use a configuration with:
 id_provider=local ?
If so, what is your use-case?

We're considering deprecating and eventually removing this provider
upstream. The replacemant for id_provider=local would be id_provider=files:
 https://fedorahosted.org/sssd/wiki/DesignDocs/FilesProvider
which is already under review and later extension of the SSSD's D-Bus
interface to allow manipulating custom user attributes.

My current plan for deprecating the local provider is to only build the
provider and the tools around it if a configure-time flag is provided.
This flag would be disabled by default. Then, if noone complains,
eventually just remove the code.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org



___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: Notify If SSSD In Cache Mode

[Mario Rossi]

What I've seen i rare cases is that sssd will print on screen when 
authenticating with cached credentials something like "User 
authenticating with cached credentials" . This would be an indication of 
sssd going in offline mode because cannot contact the ldap server ( for 
whatever other reasons )


Thanks

On 02/10/2017 08:33 AM, Douglas Duckworth wrote:

Hello

Is it possible to have SSSD notify users upon logging in that all LDAP 
servers are down and everything's being read from cache alone?


Doug

Thanks,

Douglas Duckworth, MSc, LFCS
HPC System Administrator
Scientific Computing Unit
Physiology and Biophysics
Weill Cornell Medicine
E: d...@med.cornell.edu 
O: 212-746-6305
F: 212-746-8690


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: Avoid (&(objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*))

[Mario Rossi]

I am also using custom schema and in my case I had to define the 
following 2 options for sssd to be able to 'see' them:


ldap_group_member
ldap_user_member_of

I imagine you have specific attributes you need to search/filter which 
are != than objectclass ?


Mario

On 12/20/2016 07:10 AM, Maninder Singh wrote:


Hi,

Please find the below sssd.conf. We are seeing below in LDAP logs:

SRCH base="dc=mydomain,dc=com" scope=2 deref=0 
filter="(&(uid=gdm)(objectClass=posixAccount)(&(uidNumber=*)(!(uidNumber=0"


conn=3410 op=2 SRCH attr=objectClass uid userPassword uidNumber 
gidNumber gecos homeDirectory loginShell krbPrincipalName cn 
modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax 
shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange 
krbPasswordExpiration pwdAttribute authorizedService accountExpires 
userAccountControl nsAccountLock host loginDisabled 
loginExpirationTime loginAllowedTimeMap sshPublicKey mail


We just need filter (objectClass=*) instead of the highlighted one. 
Also, we have created extra attributes which we are not able to see in 
SRCH attr. Please help.


[sssd]

config_file_version = 2

domains = default

services = nss, pam, autofs

[domain/default]

debug_level = 9

id_provider = ldap

krb5_realm = #

ldap_schema = rfc2307bis

ldap_uri = ldap://x.y.z:389

ldap_search_base = dc=mydomain,dc=com?base?|(objectClass=*)

cache_credentials = True

autofs_provider = ldap

auth_provider = ldap

chpass_provider = ldap

ldap_default_bind_dn = cn=Manager,dc=mydomain,dc=com

ldap_default_authtok =xyz

access_provider = ldap

enumerate = True

[domain/LDAP]

id_provider = ldap

ldap_uri = ldap://x.y.z:389

ldap_search_base = dc=mydomain,dc=com

cache_credentials = true

min_id = 5000

max_id = 25000

enumerate = false

[nss]

[pam]

[autofs]

Regards,

Maninder

Need an easy-to-use, OS agnostic, platform independent Test Automation 
Framework to increase ROI from your applications? Check UTAF (Unified 
Test Automation Framework) 
<%20https://hsc.com/Services/Testing-Services/Test-Automation/Unified-Test-Automation-Framework-Services?utm_source=snippet_medium=email_content=Amrita_campaign=UTAF%20>by 
HSC


DISCLAIMER: This electronic message and all of its contents, contains 
information which is privileged, confidential or otherwise protected 
from disclosure. The information contained in this electronic mail 
transmission is intended for use only by the individual or entity to 
which it is addressed. If you are not the intended recipient or may 
have received this electronic mail transmission in error, please 
notify the sender immediately and delete / destroy all copies of this 
electronic mail transmission without disclosing, copying, 
distributing, forwarding, printing or retaining any part of it. Hughes 
Systique accepts no responsibility for loss or damage arising from the 
use of the information transmitted by this email including damage from 
virus.



___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: Allow user to login only when backend offline

[Mario Rossi]

On 11/30/2016 02:47 PM, Michael Ströder wrote:

Mario Rossi wrote:

I understand your pain, I have the same issue. We have a local emargency user
in /etc/passwd and initially when we deployed servers everything was good.
And then people started to use emergency user on a daily basis

1. Make sure there's an organizational process to provide the credentials needed
for the emergency users and revoke the credentials afterwards.


Emergency users should be used when LDAP fails and there is no other way 
to get access to the box via ssh. I can recall an incident a few years 
ago where an admin deleted the bigip_monitoring user thinking that the 
account is not used. You would think that people would be able to tell 
what the user is being used for :) In this case the LB took down the 
ldap farm and emergency user was a savior until the user had been restored.



instead of their ldap accounts to bypass any ldap restrictions or
misconfiguration of the servers.

2. Make sure everything else works as expected for your users in daily life.

Ciao, Michael.



___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: generating sss_obfuscate passwords

[Mario Rossi]

Thanks Michael,

I think this is the way to go - slapd config to allow certain groups to 
write to the tree via dn.regex.

Thank you for the link.
Mario

On 11/30/2016 02:50 PM, Michael Ströder wrote:

Mario Rossi wrote:

Thank you for the information. We use both Puppet and Ansible to manage our
servers. Let me add more details:

1. An admin will build 10 new servers via cobbler and use puppet to deploy
settings
2. The admin will create a ticket to SecurityTeam who manages
openldap to create 10 new ldap entries for the server itself.

Your security team should come up with a good concept how to delegate server
entry creation to the right admins.

There are existing approaches for OpenLDAP to achieve this:

https://www.ae-dir.com/docs.html#role-setup-admin

Ciao, Michael.



___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: generating sss_obfuscate passwords

[Mario Rossi]

We're running 1.13.3 with the exception of a couple of hosts where sudo 
rules are kept in ldap and where we had to install 1.14.2 from 
unofficial repos . We had to do that because of random sudo issues in 
1.13.  On prod I would rather stay on the same version as official repo 
and not 'contaminate' the OS :)


root@b[/etc/ansible/environments]# rpm -q sssd
sssd-1.13.3-22.el6_8.4.x86_64

root@b[/etc/ansible/environments]# rpm -q centos-release
centos-release-6-8.el6.centos.12.3.x86_64

I see there is no solution to script generating lots of  encrypted 
passwords at once so I have no choice but to write custom code to save 
data to mysql, have a back-end perl script running on a test box 
connecting to the DB, running sss_obfuscate locally with DB entries and 
re-uploading them to the database where the users would pick them up via 
a web interface  :-(


Thanks

On 11/30/2016 11:22 AM, Jakub Hrozek wrote:

On Wed, Nov 30, 2016 at 11:01:51AM -0500, Mario Rossi wrote:

Jakub,

Thank you for the information. We use both Puppet and Ansible to manage our
servers. Let me add more details:

1. An admin will build 10 new servers via cobbler and use puppet to deploy
settings
2. The admin will create a ticket to SecurityTeam who manages openldap to
create 10 new ldap entries for the server itself. Each entry looks like:

uid=server1.domain.com,ou=hosts,o=mydomain,dc=domain,dc=com
[]
uid=server10.domain.com,ou=hosts,o=mydomain,dc=domain,dc=com

3. SecurityTeam will manually add above entries into LDAP tree using ADS or
shell scripts and generate random passwords for each of those 10 entries
4. SecurityTeam will connect to a test server and run sss_obfuscate 10 times
to be able to get the value of ldap_default_authtok, paste each of those
encrypted passwords into a secure tool and send it back to the admin who
requested the changes
5. The admin has to input each of those 10 'passwords' into git so
puppet/ansible can pick them up.
Is there anything more painful than the above?

(Completely untested idea)

sssd supports including configuration snippets since 1.14. Maybe you
could drop a configuration snippet with the per-host bind password into
/etc/sssd/conf.d/ with contents like:
 [domain/yourdomain]
 ldap_default_authtok_type = obfuscated_password
 ldap_default_authtok = 0xdeadbeef


Too much manual work, delays
in ticket processing, mistakes and so on. What I'm looking for is a way to
generate ldap_default_authtok in encrypted format. The sss_obfuscate tool
writes to sssd.conf, is there a way to redirect the encrypted password to
stdout instead of writing to the config file ? Unfortunately plain text
passwords are not an option in my environment - in case a server gets
compromised . I know, this is a different topic - some of the servers have
to have certain ports open to the world like 80, 443 because of business
requirements. I guess I am trying to minimize the risk of a compromise
against ldap server which is critical to the infrastructure because ldap
authentication is used by internal applications like web portals and ssh
across thousands of servers. One could argue that this is a slapd config but
it still does not resolve the above.

  Thank you

On 11/30/2016 10:07 AM, Jakub Hrozek wrote:

On Wed, Nov 30, 2016 at 09:41:51AM -0500, Mario Rossi wrote:

Hi,

sss_obfuscate is used locally on servers to replace clear text passwords in
sssd.conf. In our environment we have hundreds of servers and what I usually
do is manually generate the password on a test server. I would like to
automate ldap_default_authtok via a php interface or API. This is needed
because we use one bind DN per server and I'd like to build a web portal
where people can request new server bind DNs and randomly generated
passwords.

This is really not an SSSD question, but a generic
deployment/configuration question, so whatever you use to push the
configs to your server, be it puppet, ansible or something similar
should work.

That said, please read the manpage of sss_obfuscate. There is really no
security benefit of using obfuscated password versus a clear text bind
password, especially since sssd.conf is only redable to root. The
feature was really added to allow administrators to 'tick a box' in
environments whose security guidelines forbid them from using
a password in a config file (which is a good thing) but they can't move
away from bind passwords to something better (which is a bad thing).

It might be better to consider authenticating using something like
Kerberos keytabs.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

___
sssd-users mailing list -- sssd-users

[SSSD-users] Re: Allow user to login only when backend offline

[Mario Rossi]

Kevin,

I understand your pain, I have the same issue. We have a local emargency 
user in /etc/passwd and initially when we deployed servers everything 
was good. And then people started to use emergency user on a daily basis 
instead of their ldap accounts to bypass any ldap restrictions or 
misconfiguration of the servers. Another way is to 'hide' your user from 
/etc/passwd by using the local sssd provider but it really does not 
help. This emergency user comes in handy when you have dual factor 
authentication and you need to run a command on several servers and one 
cannot reuse the same token via Ansible for example.


I would love to know if there is a way for me to restrict emergency 
users when sssd/ldap is online without the pain of talking to each 
remote manager to enforce the existing policies. I could write a script 
to 'ping' ldap server and run commands locally but really I am against 
workarounds.


Thanks



On 11/30/2016 08:27 AM, Kevin Sullivan wrote:
On Tue, Nov 29, 2016 at 5:45 AM, Michael Ströder > wrote:


Jakub Hrozek wrote:
> On Tue, Nov 29, 2016 at 03:40:26AM -,
kevin4sulli...@gmail.com  wrote:
>> I don't want to
>> cache credentials and I can't guarantee that the account will
have been
>> used to login before LDAP is offline.
>
> Please note that the credential caching does not actually cache
> plaintext passwords, but only password hashes. Moreover, the
cache is
> only accessible to the root user.

Very good for the security. But this password caching requires
that the user has
done a successful login at least once before. That's not true in
practice
because in the DevOps world admins spin up and configure VMs and
containers
without even accessing them. Even if one admin used his password
during initial
setup the admin trying to solve a problem during the night shift
likely did not
enter his password before.

Pick your poison:

1. securely organize temporary(!) emergency access

2. LDAP deployment has to be available all times

3. sync user account and password hashes to /etc/passwd and
/etc/shadow

Ciao, Michael.


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org

To unsubscribe send an email to
sssd-users-le...@lists.fedorahosted.org



Thank you very much for responding so quickly. I always appreciate the 
intelligent and informative ideas.


I don't think I was clear with my initial message (or I have 
misunderstood your suggestions). I have no problem authenticating my 
emergency user when my LDAP backend if offline. Since I am not caching 
credentials, `pam_sss` will return a special error code (maybe 
PAM_AUTHINFO_UNAVAIL -- 9) and I am able to use `pam_unix` 
(`/etc/passwd`) to authenticate.


My problem comes when I try to authorize the user in the `account` 
section of my PAM configuration file (`/etc/pam.d/system-auth`). In my 
SSSD configuration (`/etc/sssd/sssd.conf`), I am preventing locked 
accounts from logging in with the following settings:


ldap_access_order = expire
ldap_account_expire_policy = rhds
ldap_ns_account_lock = customLockedAttribute

So my emergency account has its customLockedAttribute set to TRUE in 
LDAP, so the emergency user will be unable to log in when LDAP is 
online. However, when LDAP is offline, my emergency account is still 
unable to log in because SSSD caches the value of the 
customLockedAttribute.


Is this a better way to prevent an account from logging in when my 
backend is online?


Thanks and sorry for causing an confusion.

Kevin


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: generating sss_obfuscate passwords

[Mario Rossi]

Jakub,

Thank you for the information. We use both Puppet and Ansible to manage 
our servers. Let me add more details:


1. An admin will build 10 new servers via cobbler and use puppet to 
deploy settings
2. The admin will create a ticket to SecurityTeam who manages openldap 
to create 10 new ldap entries for the server itself. Each entry looks like:


uid=server1.domain.com,ou=hosts,o=mydomain,dc=domain,dc=com
[]
uid=server10.domain.com,ou=hosts,o=mydomain,dc=domain,dc=com

3. SecurityTeam will manually add above entries into LDAP tree using ADS 
or shell scripts and generate random passwords for each of those 10 entries
4. SecurityTeam will connect to a test server and run sss_obfuscate 10 
times to be able to get the value of ldap_default_authtok, paste each of 
those encrypted passwords into a secure tool and send it back to the 
admin who requested the changes
5. The admin has to input each of those 10 'passwords' into git so 
puppet/ansible can pick them up.


Is there anything more painful than the above? Too much manual work, 
delays in ticket processing, mistakes and so on. What I'm looking for is 
a way to generate ldap_default_authtok in encrypted format. The 
sss_obfuscate tool writes to sssd.conf, is there a way to redirect the 
encrypted password to stdout instead of writing to the config file ? 
Unfortunately plain text passwords are not an option in my environment - 
in case a server gets compromised . I know, this is a different topic - 
some of the servers have to have certain ports open to the world like 
80, 443 because of business requirements. I guess I am trying to 
minimize the risk of a compromise against ldap server which is critical 
to the infrastructure because ldap authentication is used by internal 
applications like web portals and ssh across thousands of servers. One 
could argue that this is a slapd config but it still does not resolve 
the above.


 Thank you

On 11/30/2016 10:07 AM, Jakub Hrozek wrote:

On Wed, Nov 30, 2016 at 09:41:51AM -0500, Mario Rossi wrote:

Hi,

sss_obfuscate is used locally on servers to replace clear text passwords in
sssd.conf. In our environment we have hundreds of servers and what I usually
do is manually generate the password on a test server. I would like to
automate ldap_default_authtok via a php interface or API. This is needed
because we use one bind DN per server and I'd like to build a web portal
where people can request new server bind DNs and randomly generated
passwords.

This is really not an SSSD question, but a generic
deployment/configuration question, so whatever you use to push the
configs to your server, be it puppet, ansible or something similar
should work.

That said, please read the manpage of sss_obfuscate. There is really no
security benefit of using obfuscated password versus a clear text bind
password, especially since sssd.conf is only redable to root. The
feature was really added to allow administrators to 'tick a box' in
environments whose security guidelines forbid them from using
a password in a config file (which is a good thing) but they can't move
away from bind passwords to something better (which is a bad thing).

It might be better to consider authenticating using something like
Kerberos keytabs.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org



___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] generating sss_obfuscate passwords

[Mario Rossi]

Hi,

sss_obfuscate is used locally on servers to replace clear text passwords 
in sssd.conf. In our environment we have hundreds of servers and what I 
usually do is manually generate the password on a test server. I would 
like to automate ldap_default_authtok via a php interface or API. This 
is needed because we use one bind DN per server and I'd like to build a 
web portal where people can request new server bind DNs and randomly 
generated passwords.


Is there a way?

Thank you,
Mario

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: sssd sudo issue

[Mario Rossi]

What sets the dataExpireTimestamp to 1 in the cache files ?
Should I file a bug ? Affected users cannot use sudo on certain hosts


# record 14
dn: name=stage,cn=groups,cn=DOMAIN2,cn=sysdb
createTimestamp: 1476812816
gidNumber: 16208

[]

lastUpdate: 1476816339

[]
*
**dataExpireTimestamp: 1*



root@stage ~ # sudo -U hfa-joswel-tehnicom -l
User hfa-joswel-tehnicom is not allowed to run sudo on stage.

root@stage ~ # sss_cache -E

root@stage ~ # sudo -U hfa-joswel-tehnicom -l
User hfa-joswel-tehnicom is not allowed to run sudo on stage.

root@stage ~ # id hfa-joswel-tehnicom
uid=11659(hfa-joswel-tehnicom) gid=1003() 
groups=16102(),16009(),16205(),16208(stage),1003()


root@stage ~ # sudo -U hfa-joswel-tehnicom -l
Matching Defaults entries for hfa-joswel-tehnicom on this host:
env_keep+=SSH_AUTH_SOCK, logfile=/var/log/ldap-sudo.log, 
loglinelen=0, log_year, log_host, syslog=auth, ignore_dot, 
!mail_no_user, ignore_local_sudoers,
umask=0077, umask_override, always_set_home, env_keep="COLORS 
DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1 
PS2 QTDIR USERNAME LANG
LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION 
LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC 
LC_PAPER LC_TELEPHONE",
env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET 
XAUTHORITY", secure_path=/sbin:/bin:/usr/sbin:/usr/bin, 
badpass_message=Wrong password. I have noted your
incompetence in the log. Don't think you're fooling anyone., 
!requiretty, passprompt=LDAP OnePassword for %u:


User hfa-joswel-tehnicom may run the following commands on this host:
    (ALL) PASSWD: ALL

On 10/20/2016 07:29 AM, Mario Rossi wrote:

Hi Jakub,

That is correct, I have 2 users, one is a member of DOMAIN1, the other 
is a member of DOMAIN2. The options for both domains is similar as we 
use automatic deployment system. One of the users is 
hfa-joswel-tehnicom ( test account ), the other one is azapravdin.


I thought local domain is required, I use it to inject a local 
emergency user on all servers. But I can remove local domain if it is 
recommended.


Thank you
Mario

On 10/20/2016 03:36 AM, Jakub Hrozek wrote:

On Wed, Oct 19, 2016 at 11:54:39AM -0400, Mario Rossi wrote:

Hi sssd-users list,

I am facing a strange issue on several CentOS servers. It seems that after a
while ( days ) sudo does not work any more for some of my users. We keep
rudo rules in OpenLDAP. If a user uses 'sudo su - ' , he gets a an error
message ( "User abc is not allowed to run sudo on ") however if he user
runs 'id'  followed by 'sudo su -'  then in some of the cases, it works
fine, user can get root access. I even upgraded to the unofficial repo
hoping that the issue we see is similar/same to
https://fedorahosted.org/sssd/ticket/2970. But I think it's a different
issue.

Any ideas? Next I will be looking at dumping the local sssd cache files. I
can provide debug =9 log files offline if needed.

I think this is the best course of action..

btw does the user come from DOMAIN1 or DOMAIN2?

and do you need the local domain? It's really code that mostly has
meaning for testing or experiments, I've never seen anyone using it in
production..


Thank you

root@server yum.repos.d # rpm -qa | egrep sssd
sssd-common-pac-1.13.4-4.el6.x86_64
sssd-ldap-1.13.4-4.el6.x86_64
sssd-tools-1.13.4-4.el6.x86_64
sssd-client-1.13.4-4.el6.x86_64
sssd-ad-1.13.4-4.el6.x86_64
python-sssdconfig-1.13.4-4.el6.noarch
sssd-common-1.13.4-4.el6.x86_64
sssd-ipa-1.13.4-4.el6.x86_64
sssd-proxy-1.13.4-4.el6.x86_64
sssd-krb5-common-1.13.4-4.el6.x86_64
sssd-krb5-1.13.4-4.el6.x86_64
sssd-1.13.4-4.el6.x86_64

root@server sssd # vim /etc/sssd/sssd.conf  # set debug = 9

root@server sssd # sudo -U abc -l*
**User abc is not allowed to run sudo on **server**.*

root@server sssd # egrep sudo /etc/nsswitch.conf
sudoers:sss

root@server sssd # ip a s dev eth0 | egrep global
 inet 216.X.Y.Z/26 brd 216.X.Y.Z scope global eth0


root@server sssd # id abc
uid=11044(abc) gid=1009(...) 
groups=1202(...),1168(...),1191(...),1102(...),1009(...),1101(...),1127(...),1167(...),(...),1178(...),1109(...),1199(...),1208(stage),1117(...),1198(...),1192(...),1206(...),1176(...),1404(...),1183(...),1103(...),1110(...),1205

root@abc sssd # sudo -U abc -l
Matching Defaults entries for abc on this host:
[...]

*User **abc**may run the following commands on this host:**
**(ALL) PASSWD: ALL*


# LDAP Sudo def
dn: cn=stage,ou=sudoers,o=Domain,dc=domain,dc=com
sudoOrder: 42
[...]
sudoUser: %stage
sudoRunAs: ALL
cn: stage
description: Allow Trusted Senior stuff become root
sudoCommand: ALL
sudoHost: 216.X.Y.Z
[...]
objectClass: top
objectClass: sudoRole
sudoOption: authenticate



# Group def
dn: cn=stage,ou=groups,o=Domain,dc=domain,dc=com
gidNumber: 1208
cn: stage
description: stage Group
objectClass: posixGroup
objectClass: top
memberUi

[SSSD-users] sssd sudo issue

[Mario Rossi]

Hi sssd-users list,

I am facing a strange issue on several CentOS servers. It seems that 
after a while ( days ) sudo does not work any more for some of my users. 
We keep rudo rules in OpenLDAP. If a user uses 'sudo su - ' , he gets a 
an error message ( "User abc is not allowed to run sudo on ") 
however if he user runs 'id'  followed by 'sudo su -'  then in some of 
the cases, it works fine, user can get root access. I even upgraded to 
the unofficial repo hoping that the issue we see is similar/same to 
https://fedorahosted.org/sssd/ticket/2970. But I think it's a different 
issue.


Any ideas? Next I will be looking at dumping the local sssd cache files. 
I can provide debug =9 log files offline if needed.


Thank you

root@server yum.repos.d # rpm -qa | egrep sssd
sssd-common-pac-1.13.4-4.el6.x86_64
sssd-ldap-1.13.4-4.el6.x86_64
sssd-tools-1.13.4-4.el6.x86_64
sssd-client-1.13.4-4.el6.x86_64
sssd-ad-1.13.4-4.el6.x86_64
python-sssdconfig-1.13.4-4.el6.noarch
sssd-common-1.13.4-4.el6.x86_64
sssd-ipa-1.13.4-4.el6.x86_64
sssd-proxy-1.13.4-4.el6.x86_64
sssd-krb5-common-1.13.4-4.el6.x86_64
sssd-krb5-1.13.4-4.el6.x86_64
sssd-1.13.4-4.el6.x86_64

root@server sssd # vim /etc/sssd/sssd.conf  # set debug = 9

root@server sssd # sudo -U abc -l*
**User abc is not allowed to run sudo on **server**.*

root@server sssd # egrep sudo /etc/nsswitch.conf
sudoers:sss

root@server sssd # ip a s dev eth0 | egrep global
inet 216.X.Y.Z/26 brd 216.X.Y.Z scope global eth0


root@server sssd # id abc
uid=11044(abc) gid=1009(...) 
groups=1202(...),1168(...),1191(...),1102(...),1009(...),1101(...),1127(...),1167(...),(...),1178(...),1109(...),1199(...),1208(stage),1117(...),1198(...),1192(...),1206(...),1176(...),1404(...),1183(...),1103(...),1110(...),1205


root@abc sssd # sudo -U abc -l
Matching Defaults entries for abc on this host:
[...]

*User **abc**may run the following commands on this host:**
**(ALL) PASSWD: ALL*


# LDAP Sudo def
dn: cn=stage,ou=sudoers,o=Domain,dc=domain,dc=com
sudoOrder: 42
[...]
sudoUser: %stage
sudoRunAs: ALL
cn: stage
description: Allow Trusted Senior stuff become root
sudoCommand: ALL
sudoHost: 216.X.Y.Z
[...]
objectClass: top
objectClass: sudoRole
sudoOption: authenticate



# Group def
dn: cn=stage,ou=groups,o=Domain,dc=domain,dc=com
gidNumber: 1208
cn: stage
description: stage Group
objectClass: posixGroup
objectClass: top
memberUid: abc
hMemberDN: uid=abc,ou=users,o=Domain,dc=domain,dc=com


Sanitized sssd.conf:

[sssd]
config_file_version = 2
sbus_timeout = 30
services = nss, pam, sudo, ssh
domains = LOCAL, DOMAIN1, DOMAIN2

[nss]
filter_users = 
adm,apache,avahi,bin,daemon,dbus,ecryptfs,ftp,git,games,gopher,haldaemon,halt,hfallback,ldap,lp,mail,mailnull,named,news,nfsnobody,nobody,nscd,nslcd,ntp,operator,oprofile,ossec,postfix,puppet,puppet-dashboard,pulse,pulse-access,radiusd,root,rpc,rpcuser,rtkit,saslauth,sfallback,shutdown,slocate,smmsp,sshd,sync,tcpdump,tss,uucp,vcsa
filter_groups = 
adm,apache,audio,bin,cdrom,cgred,daemon,dbus,dialout,dip,disk,ecryptfs,floppy,fuse,git,hfallback,kmem,ldap,lock,lp,mail,mailnull,man,mem,nfsnobody,nobody,nscd,ntp,ossec,oprofile,postdrop,postfix,puppet,puppet-dashboard,pulse,pulse-access,root,rpc,rpcuser,rtkit,saslauth,sfallback,slocate,smmsp,sshd,sys,tape,tcpdump,tss,tty,users,utempter,utmp,vcsa,video

override_shell = /bin/bash

[pam]
debug_level = 3
reconnection_retries = 3
offline_credentials_expiration = 2
offline_failed_login_attempts = 3
offline_failed_login_delay = 5
pam_verbosity = 1
pam_pwd_expiration_warning = 21
pam_account_expired_message = Account expired, please use selfservice 
portal to change your password and extend account.


[sudo]
debug_level=9

[ssh]
# debug_level=9

[domain/LOCAL]
description = LOCAL Users domain
id_provider = local
enumerate = true
min_id = 500
max_id = 999
default_shell = /bin/bash
base_directory = /home
create_homedir = false
remove_homedir = true
homedir_umask = 077
skel_dir = /etc/skel
mail_dir = /var/spool/mail


# SECTION: DOMAIN1
[domain/DOMAIN1]
min_id = 499
debug_level = 9
cache_credentials = True
entry_cache_timeout = 864000

auth_provider = ldap
id_provider = ldap
access_provider = ldap
#chpass_provider = ldap
sudo_provider = ldap
selinux_provider = none
autofs_provider = none


# LDAP Search
ldap_search_base = dc=domain,dc=com
ldap_group_search_base = ou=groups,o=Domain,dc=domain,dc=com
ldap_user_search_base = 
ou=users,o=Domain,dc=domain,dc=com?subtree?(|(description=cn=stage,ou=groups,o=Domain,dc=domain,dc=com)(.)(.))



# LDAP Custom Schema
ldap_group_member = hMemberDN
ldap_user_member_of = description
# this should really be rfc2307
ldap_schema = rfc2307bis

ldap_network_timeout = 3
ldap_id_use_start_tls = False
ldap_tls_reqcert = never
ldap_tls_cacertdir = /etc/openldap/cacerts

ldap_uri = ldaps://s1.sec.domain.com, ldaps://s2.sec.domain.com, 
ldaps://s3.sec.domain.com

ldap_backup_uri = ldaps://66.X.Y.Z

ldap_default_authtok_type = obfuscated_password

[SSSD-users]Re: sssd & openldap password expiration

[Mario Rossi]

Thank you Lukas.

In our environment  we only expose ldap read-only consumers and password
changes are done using a custom in-house application in php that is
accessing one of the providers in write mode. When a user changes
password, I found out that slapd will generate pwdChangedTime
non-modifiable system attribute on master so I'm not sure if that will
get replicated to the exposed consumers. We also have daily encrypted
backups of the tree for emergency cases where we might to perform a
restore. But if we do then we loose the pwdChangedTime attribute.

In lieu of this I have abandoned the idea of using password policies and
instead went with account expiration since access to production is
controlled by a set of servers and sssd can enforce account expiration
using shadowExpire ldap attribute.

For posterity the config looks like:

[pam]
.
pam_pwd_expiration_warning = 21
pam_account_expired_message = Account expired, please use selfservice
portal to change your password and extend account.

[domain/LDAP]

# SET Account expiration to shadowAccount
*ldap_account_expire_policy = shadow*

# SET Password expiration to none
*ldap_pwd_policy = none*

# SET access verification to ldap filter then check shadow account
expiration
*ldap_access_order *= filter, *expire*

ldap_chpass_update_last_change = false

# SET attribute. Redundant, It is default
ldap_user_shadow_expire   = shadowExpire
# shadowExpire: days since Jan 1, 1970 that account is disabled: $ echo
$(($(date --utc --date "$1" +%s)/86400))

Thank you

On 12/07/2015 01:20 AM, Lukas Slebodnik wrote:
> On (03/12/15 20:24), Mario Rossi wrote:
>> Hi,
>>
>> We have the need to add password (not account) expiration in ldap and I
>> see that sssd supports pwd policies. What's the recommended way of
>> achieving password expiration keeping in mind the following:
>>
>> * currently there are no shadow attributes defined ( all users have
>> shadowAccount objectclass but no attrs like shadowExpire / shadowMin /
>> shadowMax )
>> * upon the user logging in , if password is going to expire in a few
>> days, display a message to the user ( pam_account_expired_message ,
>> pam_pwd_expiration_warning ? )
>> * is sssd-1.12.4-47 rpm recommended or better sssd-1.12.5-3
> Default version in el6.7 already contians
> lockout and ppolicy options in ldap_access_order
> but it semms you want to use only "expire" which is available
> also in older versions of sssd.
>
>> <https://copr-be.cloud.fedoraproject.org/results/lslebodn/sssd-1-12/epel-6-x86_64/sssd-1.12.5-3.fc21/>?
>>
>> I found out the hard way that I need to define shadowExpire to -1
>> otherwise users get rejected with 'account has expired' message in sssd
>> debug mode but perhaps my settings are wrong. What shadow attributes
>> does sssd look for in the openldap tree ?
>>
>>
>> [pam]
>> ...
>> pam_pwd_expiration_warning = 21
>> pam_account_expired_message = Account/password expired, please use
>> selfservice portal to change your password and extend account.
>>
>>
>> [domain/LDAP]
>> ...
>> # Account expiration
>> ldap_account_expire_policy = shadow
>>
>> # Password expiration
>> #ldap_pwd_policy = none
>> ldap_pwd_policy = shadow
>> ldap_pwdlockout_dn = cn=default,ou=policies,o=Hostopia,dc=hostopia,dc=com
>> ldap_access_order = filter, expire
>>
>> pwd_expiration_warning = 21
>> ...
>>
>> Seems that I should be looking at src/providers/ldap/ldap_opts.h &
>> src/providers/ldap/sdap.h .
> looking to the manual page sssd-ldap should be ehough.
>
> LS
> ___
> sssd-users mailing list
> sssd-users@lists.fedorahosted.org
> https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
>

___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org

[SSSD-users]sssd & openldap password expiration

[Mario Rossi]

Hi,

We have the need to add password (not account) expiration in ldap and I
see that sssd supports pwd policies. What's the recommended way of
achieving password expiration keeping in mind the following:

* currently there are no shadow attributes defined ( all users have
shadowAccount objectclass but no attrs like shadowExpire / shadowMin /
shadowMax )
* upon the user logging in , if password is going to expire in a few
days, display a message to the user ( pam_account_expired_message ,
pam_pwd_expiration_warning ? )
* is sssd-1.12.4-47 rpm recommended or better sssd-1.12.5-3
<https://copr-be.cloud.fedoraproject.org/results/lslebodn/sssd-1-12/epel-6-x86_64/sssd-1.12.5-3.fc21/>?

I found out the hard way that I need to define shadowExpire to -1
otherwise users get rejected with 'account has expired' message in sssd
debug mode but perhaps my settings are wrong. What shadow attributes
does sssd look for in the openldap tree ?


[pam]
...
pam_pwd_expiration_warning = 21
pam_account_expired_message = Account/password expired, please use
selfservice portal to change your password and extend account.


[domain/LDAP]
...
# Account expiration
ldap_account_expire_policy = shadow

# Password expiration
#ldap_pwd_policy = none
ldap_pwd_policy = shadow
ldap_pwdlockout_dn = cn=default,ou=policies,o=Hostopia,dc=hostopia,dc=com
ldap_access_order = filter, expire

pwd_expiration_warning = 21
...

Seems that I should be looking at src/providers/ldap/ldap_opts.h &
src/providers/ldap/sdap.h .

Thank you,
Mario Rossi
___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org