0

The goal is to be able to add

+ : @DL-MyCompany-MyTeam : ALL

to /etc/security/access.conf and have it work as expected. This is my sssd.conf:

[domain/default]
cache_credentials = True

[sssd]
config_file_version = 2
services = nss, pam
domains = LDAP

[nss]
filter_users = backup, bin, daemon, games, gnats, irc, landscape, libuuid, list, lp, mail, man, messagebus, news, ntp, proxy, root, smmsp, smmta, sshd, sync, sys, syslog, uucp, whoopsie, www-data
allowed_shells = /bin/bash, /bin/tcsh
vetoed_shells = /bin/sh
shell_fallback = /bin/bash

[pam]

[domain/LDAP]
id_provider = ldap
auth_provider = ldap
cache_credentials = TRUE
ldap_referrals = false
ldap_uri = ldaps://10.244.128.118, ldaps://ldap.corp.example.com
ldap_search_base = dc=corp,dc=example,dc=com
ldap_schema = rfc2307bis
ldap_default_bind_dn = CN=_example,OU=ServiceAccounts,OU=Accounts_User,DC=corp,DC=example,DC=com
ldap_default_authtok_type = password
ldap_default_authtok = secret-key
ldap_tls_reqcert = never
ldap_id_use_start_tls = true
ldap_tls_cacert = /etc/ssl/certs/CORP-root.cer

ldap_user_search_base = ou=Accounts_User,dc=corp,dc=example,dc=com
ldap_group_search_base = ou=Accounts_Group,dc=corp,dc=example,dc=com?sub?gidNumber=*

ldap_user_object_class = user
ldap_user_name = sAMAccountName
ldap_user_home_directory = unixHomeDirectory
ldap_user_shell = loginShell
ldap_user_principal = userPrincipalName

ldap_group_object_class = group

override_gid = 65534

UPDATE: i've added @Andy's suggestion, then turned up the debug to 10. This is in the log:

(Thu Apr  2 12:41:33 2015) [sssd[be[LDAP]]] [be_get_account_info] (0x0100): Got request for [4098][1][name=DL-MyCompany-MyTeam]
(Thu Apr  2 12:41:33 2015) [sssd[be[LDAP]]] [be_req_set_domain] (0x0400): Changing request domain from [LDAP] to [LDAP]
(Thu Apr  2 12:41:33 2015) [sssd[be[LDAP]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection
(Thu Apr  2 12:41:33 2015) [sssd[be[LDAP]]] [sdap_get_groups_next_base] (0x0400): Searching for groups with base [ou=Accounts_Group,dc=corp,dc=example,dc=com]
(Thu Apr  2 12:41:33 2015) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(&(cn=DL-MyCompany-MyTeam)(objectclass=group)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))(gidNumber=*))][ou=Accounts_Group,dc=corp,dc=example,dc=com].
(Thu Apr  2 12:41:33 2015) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass]
(Thu Apr  2 12:41:33 2015) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn]
(Thu Apr  2 12:41:33 2015) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword]
(Thu Apr  2 12:41:33 2015) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber]
(Thu Apr  2 12:41:33 2015) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [member]
(Thu Apr  2 12:41:33 2015) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsUniqueId]
(Thu Apr  2 12:41:33 2015) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp]
(Thu Apr  2 12:41:33 2015) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged]
(Thu Apr  2 12:41:33 2015) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 10
(Thu Apr  2 12:41:33 2015) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): Trace: sh[0x998d80], connected[1], ops[0x9dc280], ldap[0x991dc0]
(Thu Apr  2 12:41:33 2015) [sssd[be[LDAP]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
(Thu Apr  2 12:41:33 2015) [sssd[be[LDAP]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set
(Thu Apr  2 12:41:33 2015) [sssd[be[LDAP]]] [sdap_get_groups_process] (0x0400): Search for groups, returned 0 results.
(Thu Apr  2 12:41:33 2015) [sssd[be[LDAP]]] [sdap_id_op_done] (0x4000): releasing operation connection

I must also point out that we're not using Kerberos on the Linux side, nor are these hosts joined to the AD realm.

rone
  • 13
  • 2
  • 6

1 Answers1

0

First may i salute you for successfully doing sssd-ad the hard way.

The simplest fix for your setup is to treat AD groups as "ldap" groups, not netgroups - remove the @ from the start of the group name

+ : DL-MyCompany-MyTeam : ALL

I'm not sure if nested groups will work as expected.

In addition, make sure pam_access is in use in /etc/pam.d

Andy
  • 1,101
  • 1
  • 7
  • 10
  • If only i could take the credit for this implementation... it works! Thank you. Now i have to do the same for sudoers. – rone Apr 01 '15 at 21:20
  • Aw, it was a false positive. My non-team member bunged their password, making me think that my work had succeeded. – rone Apr 02 '15 at 00:23
  • Are you getting any useful messages in your logs? – Andy Apr 02 '15 at 10:58
  • nope. I'm going to tear down the bizarre sssd.conf they've left me and start over from scratch. Thanks for your help. – rone Apr 02 '15 at 17:08
  • So it looks like the problem is that the 'gidNumber=*' directive returns nothing because our group entities in AD don't have that element. And even if i remove it from the conf file, it's being sent by default anyway. So i'm going to take this to the sssd-users mailing list. Your solution would work if our AD schema weren't... deficient. – rone Apr 03 '15 at 00:11
  • Welll...if you open adsiedit in AD, navigate to the user in question and browse all writable attributes, you'll see a gidnumber attribute. I think it's worth looking at "man sssd-ad" if you want to start from scratch. – Andy Apr 03 '15 at 00:45
  • Alas, i don't control AD, and any sort of schema change is not happening at this time. – rone Apr 03 '15 at 20:59
  • I understand - and will end with this clarification on a common misconception : AD has had the necessary schema for linux/unix (gidnumber, uidnumber etc) authentication since server2003, and it remains available. No schema change or modifications are needed to use those attributes, though obviously you need the right permissions to manage them. – Andy Apr 03 '15 at 21:36