[Freeipa-users] shadow netgroups with wrong domains - sudo problem
Morning, We have a collection of hosts within prod1.local.lan. However, the domain section of the shadow netgroups for the hosts is mgmt.prod.local.lan. This seems to prevent sudo rules working on these hosts unless they specify all hosts - -sh-4.2$ getent netgroup oepp_hosts oepp_hosts (oeppsdas001.z2.prod1.local.lan,-,mgmt.prod.local.lan) (oeppsdas002.z2.prod1.local.lan,-,mgmt.prod.local.lan) (oeppservice001.z2.prod1.local.lan,-,mgmt.prod.local.lan) (oeppredis002.z4.prod1.local.lan,-,mgmt.prod.local.lan) (oeppredis001.z4.prod1.local.lan,-,mgmt.prod.local.lan) -sh-4.2$ hostname oeppredis001.z4.prod1.local.lan -sh-4.2$ nisdomainname local.lan -sh-4.2$ domainname local.lan The VMs associated with these hosts have recently been migrated and re-enrolled against a new IPA server. The originals all had netgroup domains of local.lan so something must have gone wrong in the migration process. Is there a way to correct the netgroup domains of these hosts, or is the only option to run ipa-client-install --uninstall followed by ipa-client-install to reattach them ? Many thanks Bob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Adjusting nsslapd-cachememsize
While going through the logs on the FreeIPA server, I noticed this: WARNING: changelog: entry cache size 2097152 B is less than db size 12804096 B; We recommend to increase the entry cache size nsslapd-cachememsize. I have found a number of documents: What it is: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.0/html/Configuration_and_Command_Reference/Configuration_Command_File_Reference-Database_Attributes_under_cnNetscapeRoot_cnldbm_database_cnplugins_cnconfig_and_cnUserRoot_cnldbm_database_cnplugins_cnconfig-nsslapd_cachememsize.html How to tune it: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.1/html/Administration_Guide/memoryusage.html etc etc. I have no idea of what the secret password is for the "cn=directory manager" and can't find any information about where I might find it or where or when it might have been set anywhere. I have found a number of likely candidates, but none have worked. I found this page: https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password but I'd prefer to not change the password if possible. cheers L. -- The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] HBAC not working, freeipa 4.4, sssd 1.15.1
Which logs do you want from the server? -- The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper On 16 March 2017 at 20:09, Jakub Hrozek wrote: > On Thu, Mar 16, 2017 at 07:56:58PM +1100, Lachlan Musicman wrote: > > Yes. What I do would you like? Current debug levels are at 8 > > Logs and id output from the server and the client at the same time.. > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Slow logins on one ipa client- due to SSS_PAM_ACCT_MGMT
Greetings, My first post to the forum. We are running centos7 with freeipa. Syncing from AD, with one linux replica. The ipa clients are getting installed by puppet. All the clients are performing fine, except one. I am getting slow ssh logins to one host, as well as slow 'id' and 'who', etc. I turned up the sss-debuglevel to 6, and compared the slow client to another, and I am seeing a section in the logs that is unique to the slow system, basically its doing a SSS_PAM_ACCT_MGMT, and I don't have any clue why. Same user logging in to both clients, one client does the SSS_PAM_ACCT_MGMT, followed by the SSS_PAM_OPEN_SESSION. While the other client only does SSS_PAM_OPEN_SESSION, and is much faster. (1 second vs 2-8 seconds) It seems the SSS_PAM_ACCT_MGMT is the slow culprit, and I don't know why its running. Any idea what would cause this or where I should look? Below are the log for a good fast client, followed by the log from the slow client. Thanks!! Good Client [dp_get_account_info_handler] (0x0200): Got request for [0x3][BE_REQ_INITGROUPS][1][name=nob...@ipa.mydomain.org] [sysdb_get_real_name] (0x0040): Cannot find user [nob...@ipa.mydomain.org] in cache [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request [dp_get_account_info_handler] (0x0200): Got request for [0x1][BE_REQ_USER][1][name=myusern...@ipa.mydomain.org] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=myusern...@ipa.mydomain.org,cn=users,cn=ipa.mydomain.org,cn=sysdb [dp_get_account_info_handler] (0x0200): Got request for [0x1][BE_REQ_USER][1][name=myusern...@ipa.mydomain.org] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=myusern...@ipa.mydomain.org,cn=users,cn=ipa.mydomain.org,cn=sysdb [dp_get_account_info_handler] (0x0200): Got request for [0x3][BE_REQ_INITGROUPS][1][name=myusern...@ipa.mydomain.org] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=myusern...@ipa.mydomain.org,cn=users,cn=ipa.mydomain.org,cn=sysdb [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=myusern...@ipa.mydomain.org,cn=users,cn=ipa.mydomain.org,cn=sysdb [dp_pam_handler] (0x0100): Got request with the following data [pam_print_data] (0x0100): command: SSS_PAM_OPEN_SESSION [pam_print_data] (0x0100): domain: ipa.mydomain.org [pam_print_data] (0x0100): user: myusern...@ipa.mydomain.org [pam_print_data] (0x0100): service: sshd [pam_print_data] (0x0100): tty: ssh [pam_print_data] (0x0100): ruser: [pam_print_data] (0x0100): rhost: myhost.mydomain.org [pam_print_data] (0x0100): authtok type: 0 [pam_print_data] (0x0100): newauthtok type: 0 [pam_print_data] (0x0100): priv: 1 [pam_print_data] (0x0100): cli_pid: 26697 [pam_print_data] (0x0100): logon name: not set Bad Client [dp_get_account_info_handler] (0x0200): Got request for [0x3][BE_REQ_INITGROUPS][1][name=nob...@ipa.mydomain.org] [sysdb_get_real_name] (0x0040): Cannot find user [nob...@ipa.mydomain.org] in cache [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request [dp_get_account_info_handler] (0x0200): Got request for [0x1][BE_REQ_USER][1][name=myusern...@ipa.mydomain.org] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=myusern...@ipa.mydomain.org,cn=users,cn=ipa.mydomain.org,cn=sysdb [dp_get_account_info_handler] (0x0200): Got request for [0x1][BE_REQ_USER][1][name=myusern...@ipa.mydomain.org] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=myusern...@ipa.mydomain.org,cn=users,cn=ipa.mydomain.org,cn=sysdb [dp_get_account_info_handler] (0x0200): Got request for [0x3][BE_REQ_INITGROUPS][1][name=myusern...@ipa.mydomain.org] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=myusern...@ipa.mydomain.org,cn=users,cn=ipa.mydomain.org,cn=sysdb [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=myusern...@ipa.mydomain.org,cn=users,cn=ipa.mydomain.org,cn=sysdb [dp_pam_handler] (0x0100): Got request with the following data [pam_print_data] (0x0100): command: SSS_PAM_ACCT_MGMT [pam_print_data] (0x0100): domain: ipa.mydomain.org [pam_print_data] (0x0100): user: myusern...
[Freeipa-users] Manual Cleanup
I've made some progress. But I have one zombie replication agreement to
kill, I just don't know the syntax.
freeipa-dal.bpt.rocks does not exist. I want all references to it to go
away.
How would I do that with ldapmodify?
Thanks!
[root@freeipa-sea slapd-BPT-ROCKS]# ldapsearch -D "cn=directory
manager" -w ... -b "o=ipaca"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
nscpentrywsi
# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter:
(&(objectclass=nstombstone)(nsUniqueId=---))
# requesting: nscpentrywsi
#
# replica, o\3Dipaca, mapping tree, config
dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
nscpentrywsi: cn: replica
nscpentrywsi: createTimestamp: 20160814234939Z
nscpentrywsi: creatorsName: cn=directory manager
nscpentrywsi: modifiersName: cn=Multimaster Replication
Plugin,cn=plugins,cn=c
onfig
nscpentrywsi: modifyTimestamp: 20170316181544Z
nscpentrywsi: nsDS5Flags: 1
nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager
cloneAgreement1-freei
pa-sea.bpt.rocks-pki-tomcat,ou=csusers,cn=config
nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager
masterAgreement1-free
ipa-dal.bpt.rocks-pki-tomcat,ou=csusers,cn=config
nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager
masterAgreement1-seat
tlenfs.bpt.rocks-pki-tomcat,ou=csusers,cn=config
nscpentrywsi: nsDS5ReplicaId: 1065
nscpentrywsi: nsDS5ReplicaName: b21a1f1e-627911e6-93e6ef4b-69dcc2d1
nscpentrywsi: nsDS5ReplicaRoot: o=ipaca
nscpentrywsi: nsDS5ReplicaType: 3
nscpentrywsi: nsState::
KQQAAABO1spYKg
==
nscpentrywsi: nsds5replicabinddngroup: cn=replication
managers,cn=sysaccounts,
cn=etc,dc=bpt,dc=rocks
nscpentrywsi: nsds5replicabinddngroupcheckinterval: 60
nscpentrywsi: objectClass: top
nscpentrywsi: objectClass: nsDS5Replica
nscpentrywsi: objectClass: extensibleobject
nscpentrywsi: numSubordinates: 2
nscpentrywsi: nsds50ruv: {replicageneration} 57c291d90429
nscpentrywsi: nsds50ruv: {replica 1065 ldap://freeipa-sea.bpt.rocks:389}
57f84
0bf0429 58cad6670429
nscpentrywsi: nsds50ruv: {replica 1290 ldap://seattlenfs.bpt.rocks:389}
nscpentrywsi: nsds50ruv: {replica 1295 ldap://freeipa-dal.bpt.rocks:389}
nscpentrywsi: nsds5agmtmaxcsn:
o=ipaca;cloneAgreement1-freeipa-sea.bpt.rocks-p
ki-tomcat;seattlenfs.bpt.rocks;389;unavailable
nscpentrywsi: nsds5agmtmaxcsn:
o=ipaca;masterAgreement1-seattlenfs.bpt.rocks-p
ki-tomcat;seattlenfs.bpt.rocks;389;unavailable
nscpentrywsi: nsruvReplicaLastModified: {replica 1065
ldap://freeipa-sea.bpt.r
ocks:389} 58cad63d
nscpentrywsi: nsruvReplicaLastModified: {replica 1290
ldap://seattlenfs.bpt.ro
cks:389}
nscpentrywsi: nsruvReplicaLastModified: {replica 1295
ldap://freeipa-dal.bpt.r
ocks:389}
nscpentrywsi: nsds5ReplicaChangeCount: 15993
nscpentrywsi: nsds5replicareapactive: 0
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
[root@freeipa-sea slapd-BPT-ROCKS]# ipa-csreplica-manage del
freeipa-dal.bpt.rocks --forceDirectory Manager password:
'freeipa-sea.bpt.rocks' has no replication agreement for
'freeipa-dal.bpt.rocks'
[root@freeipa-sea slapd-BPT-ROCKS]# ipa-replica-manage list
seattlenfs.bpt.rocks: master
freeipa-dal.bpt.rocks: master
freeipa-sea.bpt.rocks: master
[root@freeipa-sea slapd-BPT-ROCKS]# ipa-replica-manage list
freeipa-sea.bpt.rocks
seattlenfs.bpt.rocks: replica
[root@freeipa-sea slapd-BPT-ROCKS]# ipa-csreplica-manage list
Directory Manager password:
seattlenfs.bpt.rocks: master
freeipa-dal.bpt.rocks: CA not configured
freeipa-sea.bpt.rocks: master
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] replica install seems to hang forever when "--setup-ca" is enabled - any advice?
That looks exactly like my issue, thanks! Will monitor that ticket. Much appreciated. Martin Basti wrote: Could it be this? https://pagure.io/freeipa/issue/6766 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] HBAC not working, freeipa 4.4, sssd 1.15.1
On Thu, Mar 16, 2017 at 07:56:58PM +1100, Lachlan Musicman wrote: > Yes. What I do would you like? Current debug levels are at 8 Logs and id output from the server and the client at the same time.. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] HBAC not working, freeipa 4.4, sssd 1.15.1
Yes. What I do would you like? Current debug levels are at 8 L. On 16 Mar. 2017 7:06 pm, "Jakub Hrozek" wrote: > On Thu, Mar 16, 2017 at 11:36:57AM +1100, Lachlan Musicman wrote: > > I'm experiencing issues with HBAC and I think it's a bug in sssd. Not > sure > > if better to report to here or sssd mailing list. Also sssd in pagure is > > bare and I didn't want to sully the blank slate. ( > > https://pagure.io/sssd/issues ) > > > > The details: > > > > env: CentOS 7.3, FreeIPA 4.4, sssd 1.15.1 from COPR > > > > On the IPA server: > > > > - "ipa hbactest ..." returns TRUE, so everything seems set up correctly. > > > > > > When I try to login to the test client, I get denied. > > > > On the test client: > > > > - hbac_eval_user_element is returning a wrong value. This is seen in > > sssd_domain.log, it's returning 25. My test user is in 37 groups. This is > > seen on the IPA server via id username. On the test client id username > > returns 36 groups, the one missing is an IPA (not AD) group that was made > > for HBAC rules. I have sanitized logs available. > > > > - taking ldbsearch -H /var/lib/sss/db/cache_domain.com.ldb > > '(objectclass=user)' and finding the record in question shows the same 36 > > groups available. The missing group shouldn't affect ability to login via > > HBAC > > > > - getent group (groupname) works as expected. Also worth noting that the > > group missing from id username shows that user in getent. > > > > For reference, on the client the sssd service was stopped, the cache > > deleted, and the service started again the night before after which the > > server wasn't accessed by anyone. I find that this is necessary for the > > cache to populate. > > > > Should I put in a bug report against SSSD or FreeIPA? > > > > While HBAC is in FreeIPA, I think that this is an issue in SSSD > > (specifically ? > > Yes, SSSD. > > I remember you had some intermittent issues in the past, is this one > reproducable? > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] replica install seems to hang forever when "--setup-ca" is enabled - any advice?
On 16.03.2017 01:34, Fraser Tweedale wrote: > On Wed, Mar 15, 2017 at 06:32:42PM -0400, Chris Dagdigian wrote: >> Any tips for diving into this a bit more to troubleshoot? >> >> For the 1st time I'm setting up an ipa-server 4.4 replica with CA features >> enabled but the replica install seems to hang forever here: >> >> ... >> ... >> ... >> Done configuring directory server (dirsrv). >> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30 >> seconds >> [1/27]: creating certificate server user >> [2/27]: configuring certificate server instance >> [3/27]: stopping certificate server instance to update CS.cfg >> [4/27]: backing up CS.cfg >> [5/27]: disabling nonces >> [6/27]: set up CRL publishing >> [7/27]: enable PKIX certificate path discovery and validation >> [8/27]: starting certificate server instance >> >> < no output after this > >> >> >> The replica-install.log file ends here: >> >> ... >> ... >> ... >> 2017-03-15T22:16:05Z DEBUG Starting external process >> 2017-03-15T22:16:05Z DEBUG args=/bin/systemctl is-active >> pki-tomcatd@pki-tomcat.service >> 2017-03-15T22:16:05Z DEBUG Process finished, return code=0 >> 2017-03-15T22:16:05Z DEBUG stdout=active >> >> 2017-03-15T22:16:05Z DEBUG stderr= >> 2017-03-15T22:16:05Z DEBUG wait_for_open_ports: localhost [8080, 8443] >> timeout 300 >> 2017-03-15T22:16:06Z DEBUG Waiting until the CA is running >> 2017-03-15T22:16:06Z DEBUG request POST >> http://deawilidmp001.XXX.org:8080/ca/admin/ca/getStatus >> 2017-03-15T22:16:06Z DEBUG request body '' >> >> >> >> >> I've confirmed that SELINUX is disabled, there is no firewall and the AWS >> Security Groups are allowing TCP:8080 and TCP:8443 to the replica instance. >> The systemctl command also verifies that >> pki-tomcatd@pki-tomcat.service is "active" as well. >> >> >> Any tips for debugging further? >> > Could you please provide the /var/log/pki/pki-tomcat/ca/debug log > file? > > Thanks, > Fraser > Could it be this? https://pagure.io/freeipa/issue/6766 signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] HBAC not working, freeipa 4.4, sssd 1.15.1
On Thu, Mar 16, 2017 at 11:36:57AM +1100, Lachlan Musicman wrote: > I'm experiencing issues with HBAC and I think it's a bug in sssd. Not sure > if better to report to here or sssd mailing list. Also sssd in pagure is > bare and I didn't want to sully the blank slate. ( > https://pagure.io/sssd/issues ) > > The details: > > env: CentOS 7.3, FreeIPA 4.4, sssd 1.15.1 from COPR > > On the IPA server: > > - "ipa hbactest ..." returns TRUE, so everything seems set up correctly. > > > When I try to login to the test client, I get denied. > > On the test client: > > - hbac_eval_user_element is returning a wrong value. This is seen in > sssd_domain.log, it's returning 25. My test user is in 37 groups. This is > seen on the IPA server via id username. On the test client id username > returns 36 groups, the one missing is an IPA (not AD) group that was made > for HBAC rules. I have sanitized logs available. > > - taking ldbsearch -H /var/lib/sss/db/cache_domain.com.ldb > '(objectclass=user)' and finding the record in question shows the same 36 > groups available. The missing group shouldn't affect ability to login via > HBAC > > - getent group (groupname) works as expected. Also worth noting that the > group missing from id username shows that user in getent. > > For reference, on the client the sssd service was stopped, the cache > deleted, and the service started again the night before after which the > server wasn't accessed by anyone. I find that this is necessary for the > cache to populate. > > Should I put in a bug report against SSSD or FreeIPA? > > While HBAC is in FreeIPA, I think that this is an issue in SSSD > (specifically ? Yes, SSSD. I remember you had some intermittent issues in the past, is this one reproducable? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
