[Freeipa-users] FreeIPA default_ccache_name in systemd-nspawn container

[Anthony Joseph Messina]

I've been running freeipa-server-4.x.x.fc25.x86_64 in systemd-nspawn selinux-
wrapped full OS containers for a while.

After upgrading to F25 on the host, systemd disabled access to the KEYRING 
ccache type from nspawn containers since the kernel keyring isn't namespaced. 
So anything that needs to get a keytab results in something like the 
following.

-bash-4.3# kinit
kinit: Invalid UID in persistent keyring name while getting default ccache

dnf upgrades end up failing until I 'export KRB5CCNAME=FILE:/tmp/whatever' and 
manually upgrade as if I performed an offline upgrade.

Other than that, no issues to report.

Are there any concerns if I switch the krb5.com default_ccache_name on the 
freeipa systemd-nspawn servers to MEMORY or FILE?  Which would be preferred?

Thanks for the advice.  -A

-- 
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
F9B6 560E 68EA 037D 8C3D  D1C9 FF31 3BDB D9D8 99B6

-- 
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] shadow netgroups with wrong domains - sudo problem

[Bob Hinton]

On 17/03/2017 14:01, Lukas Slebodnik wrote:
> On (17/03/17 13:52), Bob Hinton wrote:
>> On 17/03/2017 12:48, Lukas Slebodnik wrote:
>>> On (17/03/17 10:40), Bob Hinton wrote:
 On 17/03/2017 08:41, Jakub Hrozek wrote:
> On Fri, Mar 17, 2017 at 06:50:34AM +, Bob Hinton wrote:
>> 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 ?
> Did you remove the sssd cache after the migration?
> rm -f /var/lib/sss/db/*.ldb
>
> (please make sure the clients can reach the server or maybe mv the cache
> instead of rm so you can restore cached credentials if something goes
> wrong..)
>
 Hi Jakub,

 I've now tried removing the sssd cache on one of the offending servers
 and it's not made any difference.

 getent netgroup oepp_hosts

 when run from any host enrolled to the new IPA servers, including the
 IPA masters themselves produces the results with "mgmt.prod" included
 and the same thing run on any of the pre-migrated servers that are still
 commissioned produces them without, so I assume that the netgroup domain
 information is coming from the IPA masters rather than the local host.

>>> Could you provide content of LDIF from IPA server?
>>> For this netgroup/hostgroup
>>>
>>> LS
>> Hi Jakub,
>>
>> I extracted the following from the userRoot ldif produced by "ipa-backup
>> --data".
>>
>> It appears to have the incorrect domain set against nisDomainName. Could
>> this be changed with ldapmodify ?
>>
>> Thanks
>>
>> Bob
>>
>> # entry-id: 1485
>> dn: cn=oepp_hosts,cn=ng,cn=alt,dc=local,dc=lan
>> ipaUniqueID: 186461fa-f91d-11e6-b43d-06642ebde14b
>> modifyTimestamp: 20170222163643Z
>> createTimestamp: 20170222163643Z
>> modifiersName: cn=Managed Entries,cn=plugins,cn=config
>> creatorsName: cn=Managed Entries,cn=plugins,cn=config
>> mepManagedBy: cn=oepp_hosts,cn=hostgroups,cn=accounts,dc=local,dc=lan
>> description: ipaNetgroup oepp_hosts
>> memberHost: cn=oepp_hosts,cn=hostgroups,cn=accounts,dc=local,dc=lan
>> cn: oepp_hosts
>> nisDomainName: mgmt.prod.local.lan
> And value of this attribute is an explanation to your question
> why there is a different domain in netgroups.
>
>> objectClass: ipanisnetgroup
>> objectClass: ipaobject
>> objectClass: mepManagedEntry
>> objectClass: ipaAssociation
>> objectClass: top
>> nsUniqueId: f834f7a7-f91c11e6-a7d5eda5-d52d2b10
> LS
>
Hi Jakub,

I've tried using ldapsearch to retrieve this record but the results
don't include the nisDomainName field. Can you give me any pointers how
to access this attribute so I can edit it ?

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

Re: [Freeipa-users] Slow logins on one ipa client- due to SSS_PAM_ACCT_MGMT

[Kilborn, Jim]

Justin,

I verified that the pam.d files were as you documented, and they were the same 
between the two clients. However, I forgot that I had a local user defined that 
matched the account name. That was stupid of me. I removed the local user, and 
now it is doing the  SSS_PAM_ACCT_MGMT, so at least I'm not chasing that 
anymore.

The client speed is still much different, so I need to compare the logs again 
and see where its taking up so much time. Hopefully it will be more apparent 
now. 

Much Thanks !!

Regards,
Jim


> -Original Message-
> From: Justin Stephenson [mailto:jstep...@redhat.com]
> Sent: Friday, March 17, 2017 1:12 PM
> To: Kilborn, Jim ; Jakub Hrozek
> ; freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Slow logins on one ipa client- due to
> SSS_PAM_ACCT_MGMT
> 
> On 03/17/2017 11:27 AM, Kilborn, Jim wrote:
> > Jakub,
> >
> > Thanks for the response...
> >
> > I already had the selinux_provider=none in the sssd.conf
> > Tthe sssd.conf is identical on both clients, with the exception of
> ipa_hostname
> >
> >
> > [domain/ipa.mydomain.org]
> > selinux_provider = none
> > cache_credentials = True
> > krb5_store_password_if_offline = True
> > ipa_domain = ipa.mydomain.org
> > id_provider = ipa
> > auth_provider = ipa
> > access_provider = ipa
> > ldap_tls_cacert = /etc/ipa/ca.crt
> > ipa_hostname = darkjedi-master01.div18.swri.edu
> > chpass_provider = ipa
> > ipa_server = _srv_, div18auth1.ipa.mydomain.org,
> div18auth2.ipa.mydomain.org
> > dns_discovery_domain = ipa.mydomain.org
> > [sssd]
> > services = nss, sudo, pam, ssh
> > config_file_version = 2
> > domains = ipa.mydomain.org
> > [nss]
> > homedir_substring = /home
> > [pam]
> > [sudo]
> > [autofs]
> > [ssh]
> > [pac]
> > [ifp]
> >
> > I verified the all the files in /etc/pam.d are the same on both clients 
> > using
> the checksum of the files.
> >
> > I turned logging up to 8 on both clients, and everything is fine until this 
> > part
> appears. Can't figure out why the slow host receives an extra request. The
> sssd_be client process is getting this request from where?
> 
> It is expected for the login process to make a call into pam_acct_mgmt()
> which should trigger pam_sss in the 'account' section of the PAM stack
> for IPA users. This behavior is dependent on the PAM stack
> configuration, I would say the system that never calls
> SSS_PAM_ACCT_MGMT
> is the non-working one in this case.
> 
> I understand you said they are the exact same, but I would suggest
> checking closely the 'account' section in /etc/pam.d/sshd and
> /etc/pam.d/password-auth.
> 
> In the version you are running, the password-auth account section should
> look similar to:
> 
>  account required  pam_unix.so
>  account sufficientpam_localuser.so
>  account sufficientpam_succeed_if.so uid < 1000 quiet
>  account [default=bad success=ok user_unknown=ignore] pam_sss.so
>  account required  pam_permit.so
> 
> > After it finished up the SSS_PAM_ACCT_MGMT request, the slow client
> runs the SSS_PAM_OPEN_SESSION, which is fast, just like the fast client. Its
> wasting time in the SSS_PAM_ACCT_MGMT request, and I don't understand
> why that request is being received  by sssd_be.
> 
> Is it possible a local user exists with the same name that you are
> trying to login as? In this case that may cause the pam_sss line entry
> in the PAM stack to never be reached(they would 'succeed' the account
> section in one of the previous modules).
> 
> >
> > Slow Client
> > (Fri Mar 17 09:17:33 2017) [sssd[be[ipa.div18.swri.org]]] [dp_pam_handler]
> (0x0100): Got request with the following data
> > (Fri Mar 17 09:17:33 2017) [sssd[be[ipa.div18.swri.org]]] [pam_print_data]
> (0x0100): command: SSS_PAM_ACCT_MGMT   <- Why does the slow client
> get this request first?
> >
> > Fast Client
> > (Fri Mar 17 09:16:34 2017) [sssd[be[ipa.div18.swri.org]]] [dp_pam_handler]
> (0x0100): Got request with the following data
> > (Fri Mar 17 09:16:34 2017) [sssd[be[ipa.div18.swri.org]]] [pam_print_data]
> (0x0100): command: SSS_PAM_OPEN_SESSION
> >
> >
> > Also ipa version is 4.4.0
> >
> >
> > Regards,
> > Jim
> >
> >> 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 

[Freeipa-users] different apis for adding "local" users to groups vs adding users from cft?

[Marc Boorshtein]

I've got the api integrated for all local users and am looking at if
there are any differences between that and if my ipa domain is in a
CFT with an AD domain.  Right now I'm using "group_add_member", should
that work for users coming from a trusted forest as well?

Thanks

Marc Boorshtein
CTO Tremolo Security
marc.boorsht...@tremolosecurity.com
Twitter - @mlbiam / @tremolosecurity

-- 
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] Slow logins on one ipa client- due to SSS_PAM_ACCT_MGMT

[Justin Stephenson]

On 03/17/2017 11:27 AM, Kilborn, Jim wrote:

Jakub,

Thanks for the response...

I already had the selinux_provider=none in the sssd.conf
Tthe sssd.conf is identical on both clients, with the exception of ipa_hostname


[domain/ipa.mydomain.org]
selinux_provider = none
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = ipa.mydomain.org
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ldap_tls_cacert = /etc/ipa/ca.crt
ipa_hostname = darkjedi-master01.div18.swri.edu
chpass_provider = ipa
ipa_server = _srv_, div18auth1.ipa.mydomain.org, div18auth2.ipa.mydomain.org
dns_discovery_domain = ipa.mydomain.org
[sssd]
services = nss, sudo, pam, ssh
config_file_version = 2
domains = ipa.mydomain.org
[nss]
homedir_substring = /home
[pam]
[sudo]
[autofs]
[ssh]
[pac]
[ifp]

I verified the all the files in /etc/pam.d are the same on both clients using 
the checksum of the files.

I turned logging up to 8 on both clients, and everything is fine until this 
part appears. Can't figure out why the slow host receives an extra request. The 
sssd_be client process is getting this request from where?


It is expected for the login process to make a call into pam_acct_mgmt() 
which should trigger pam_sss in the 'account' section of the PAM stack 
for IPA users. This behavior is dependent on the PAM stack 
configuration, I would say the system that never calls SSS_PAM_ACCT_MGMT 
is the non-working one in this case.


I understand you said they are the exact same, but I would suggest 
checking closely the 'account' section in /etc/pam.d/sshd and 
/etc/pam.d/password-auth.


In the version you are running, the password-auth account section should 
look similar to:


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


After it finished up the SSS_PAM_ACCT_MGMT request, the slow client runs the 
SSS_PAM_OPEN_SESSION, which is fast, just like the fast client. Its wasting 
time in the SSS_PAM_ACCT_MGMT request, and I don't understand why that request 
is being received  by sssd_be.


Is it possible a local user exists with the same name that you are 
trying to login as? In this case that may cause the pam_sss line entry 
in the PAM stack to never be reached(they would 'succeed' the account 
section in one of the previous modules).




Slow Client
(Fri Mar 17 09:17:33 2017) [sssd[be[ipa.div18.swri.org]]] [dp_pam_handler] 
(0x0100): Got request with the following data
(Fri Mar 17 09:17:33 2017) [sssd[be[ipa.div18.swri.org]]] [pam_print_data] 
(0x0100): command: SSS_PAM_ACCT_MGMT   <- Why does the slow client get this 
request first?

Fast Client
(Fri Mar 17 09:16:34 2017) [sssd[be[ipa.div18.swri.org]]] [dp_pam_handler] 
(0x0100): Got request with the following data
(Fri Mar 17 09:16:34 2017) [sssd[be[ipa.div18.swri.org]]] [pam_print_data] 
(0x0100): command: SSS_PAM_OPEN_SESSION


Also ipa version is 4.4.0


Regards,
Jim


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?


The timestamps from the logs are missing, so it's not clear which call is 
taking long. No server lookups should be performed in the account phase, 
though, so I can only think of the selinux label setting in libselinux, which 
is also done in the account phase to be taking long.

can you try to disable the selinux provider for a test?
selinux_provider=none
btw why is the 'fast' client not running the account phase at all? Is pam_sss 
in the account stack in the PAM configuration? Is the access_provider set to 
anything else than IPA in the sssd.conf file?

--
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] Manual Cleanup

[Petr Vobornik]

On 03/16/2017 07:14 PM, Ian Harding wrote:

I've made some progress.  But I have one zombie replication agreement to
kill, I just don't know the syntax.


The output listed below is not replication agreement. But there is 
reference to RUV.




freeipa-dal.bpt.rocks does not exist.  I want all references to it to go
away.

How would I do that with ldapmodify?


I wouldn't delete the entry below because 
cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config is a container for CA 
replication agreements and it should stay there. Btw, there should also 
be one for "domain" replication agreements.


But in general, you could use ldapdelete command.

If you want to investigate pure ldap data, then information about IPA 
masters is also stored in cn=masters,cn=ipa,cn=etc,dc=example,dc=test . 
This is the place where ipa server-find gets its info.




Thanks!


[root@freeipa-sea slapd-BPT-ROCKS]# ldapsearch  -D "cn=directory
manager" -w ... -b "o=ipaca"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
nscpentrywsi
# extended LDIF
#
# LDAPv3
# base 

Re: [Freeipa-users] Slow logins on one ipa client- due to SSS_PAM_ACCT_MGMT

[Kilborn, Jim]

Jakub,

Thanks for the response...

I already had the selinux_provider=none in the sssd.conf
Tthe sssd.conf is identical on both clients, with the exception of ipa_hostname


[domain/ipa.mydomain.org]
selinux_provider = none
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = ipa.mydomain.org
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ldap_tls_cacert = /etc/ipa/ca.crt
ipa_hostname = darkjedi-master01.div18.swri.edu
chpass_provider = ipa
ipa_server = _srv_, div18auth1.ipa.mydomain.org, div18auth2.ipa.mydomain.org
dns_discovery_domain = ipa.mydomain.org
[sssd]
services = nss, sudo, pam, ssh
config_file_version = 2
domains = ipa.mydomain.org
[nss]
homedir_substring = /home
[pam]
[sudo]
[autofs]
[ssh]
[pac]
[ifp]

I verified the all the files in /etc/pam.d are the same on both clients using 
the checksum of the files.

I turned logging up to 8 on both clients, and everything is fine until this 
part appears. Can't figure out why the slow host receives an extra request. The 
sssd_be client process is getting this request from where?
After it finished up the SSS_PAM_ACCT_MGMT request, the slow client runs the 
SSS_PAM_OPEN_SESSION, which is fast, just like the fast client. Its wasting 
time in the SSS_PAM_ACCT_MGMT request, and I don't understand why that request 
is being received  by sssd_be. 

Slow Client
(Fri Mar 17 09:17:33 2017) [sssd[be[ipa.div18.swri.org]]] [dp_pam_handler] 
(0x0100): Got request with the following data
(Fri Mar 17 09:17:33 2017) [sssd[be[ipa.div18.swri.org]]] [pam_print_data] 
(0x0100): command: SSS_PAM_ACCT_MGMT   <- Why does the slow client get this 
request first?

Fast Client
(Fri Mar 17 09:16:34 2017) [sssd[be[ipa.div18.swri.org]]] [dp_pam_handler] 
(0x0100): Got request with the following data
(Fri Mar 17 09:16:34 2017) [sssd[be[ipa.div18.swri.org]]] [pam_print_data] 
(0x0100): command: SSS_PAM_OPEN_SESSION


Also ipa version is 4.4.0


Regards,
Jim

> 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?

The timestamps from the logs are missing, so it's not clear which call is 
taking long. No server lookups should be performed in the account phase, 
though, so I can only think of the selinux label setting in libselinux, which 
is also done in the account phase to be taking long.

can you try to disable the selinux provider for a test?
selinux_provider=none
btw why is the 'fast' client not running the account phase at all? Is pam_sss 
in the account stack in the PAM configuration? Is the access_provider set to 
anything else than IPA in the sssd.conf file?

--
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] shadow netgroups with wrong domains - sudo problem

[Lukas Slebodnik]

On (17/03/17 13:52), Bob Hinton wrote:
>On 17/03/2017 12:48, Lukas Slebodnik wrote:
>> On (17/03/17 10:40), Bob Hinton wrote:
>>> On 17/03/2017 08:41, Jakub Hrozek wrote:
 On Fri, Mar 17, 2017 at 06:50:34AM +, Bob Hinton wrote:
> 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 ?
 Did you remove the sssd cache after the migration?
 rm -f /var/lib/sss/db/*.ldb

 (please make sure the clients can reach the server or maybe mv the cache
 instead of rm so you can restore cached credentials if something goes
 wrong..)

>>> Hi Jakub,
>>>
>>> I've now tried removing the sssd cache on one of the offending servers
>>> and it's not made any difference.
>>>
>>> getent netgroup oepp_hosts
>>>
>>> when run from any host enrolled to the new IPA servers, including the
>>> IPA masters themselves produces the results with "mgmt.prod" included
>>> and the same thing run on any of the pre-migrated servers that are still
>>> commissioned produces them without, so I assume that the netgroup domain
>>> information is coming from the IPA masters rather than the local host.
>>>
>> Could you provide content of LDIF from IPA server?
>> For this netgroup/hostgroup
>>
>> LS
>
>Hi Jakub,
>
>I extracted the following from the userRoot ldif produced by "ipa-backup
>--data".
>
>It appears to have the incorrect domain set against nisDomainName. Could
>this be changed with ldapmodify ?
>
>Thanks
>
>Bob
>
># entry-id: 1485
>dn: cn=oepp_hosts,cn=ng,cn=alt,dc=local,dc=lan
>ipaUniqueID: 186461fa-f91d-11e6-b43d-06642ebde14b
>modifyTimestamp: 20170222163643Z
>createTimestamp: 20170222163643Z
>modifiersName: cn=Managed Entries,cn=plugins,cn=config
>creatorsName: cn=Managed Entries,cn=plugins,cn=config
>mepManagedBy: cn=oepp_hosts,cn=hostgroups,cn=accounts,dc=local,dc=lan
>description: ipaNetgroup oepp_hosts
>memberHost: cn=oepp_hosts,cn=hostgroups,cn=accounts,dc=local,dc=lan
>cn: oepp_hosts
>nisDomainName: mgmt.prod.local.lan
And value of this attribute is an explanation to your question
why there is a different domain in netgroups.

>objectClass: ipanisnetgroup
>objectClass: ipaobject
>objectClass: mepManagedEntry
>objectClass: ipaAssociation
>objectClass: top
>nsUniqueId: f834f7a7-f91c11e6-a7d5eda5-d52d2b10

LS

-- 
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] shadow netgroups with wrong domains - sudo problem

[Bob Hinton]

On 17/03/2017 12:48, Lukas Slebodnik wrote:
> On (17/03/17 10:40), Bob Hinton wrote:
>> On 17/03/2017 08:41, Jakub Hrozek wrote:
>>> On Fri, Mar 17, 2017 at 06:50:34AM +, Bob Hinton wrote:
 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 ?
>>> Did you remove the sssd cache after the migration?
>>> rm -f /var/lib/sss/db/*.ldb
>>>
>>> (please make sure the clients can reach the server or maybe mv the cache
>>> instead of rm so you can restore cached credentials if something goes
>>> wrong..)
>>>
>> Hi Jakub,
>>
>> I've now tried removing the sssd cache on one of the offending servers
>> and it's not made any difference.
>>
>> getent netgroup oepp_hosts
>>
>> when run from any host enrolled to the new IPA servers, including the
>> IPA masters themselves produces the results with "mgmt.prod" included
>> and the same thing run on any of the pre-migrated servers that are still
>> commissioned produces them without, so I assume that the netgroup domain
>> information is coming from the IPA masters rather than the local host.
>>
> Could you provide content of LDIF from IPA server?
> For this netgroup/hostgroup
>
> LS

Hi Jakub,

I extracted the following from the userRoot ldif produced by "ipa-backup
--data".

It appears to have the incorrect domain set against nisDomainName. Could
this be changed with ldapmodify ?

Thanks

Bob

# entry-id: 1485
dn: cn=oepp_hosts,cn=ng,cn=alt,dc=local,dc=lan
ipaUniqueID: 186461fa-f91d-11e6-b43d-06642ebde14b
modifyTimestamp: 20170222163643Z
createTimestamp: 20170222163643Z
modifiersName: cn=Managed Entries,cn=plugins,cn=config
creatorsName: cn=Managed Entries,cn=plugins,cn=config
mepManagedBy: cn=oepp_hosts,cn=hostgroups,cn=accounts,dc=local,dc=lan
description: ipaNetgroup oepp_hosts
memberHost: cn=oepp_hosts,cn=hostgroups,cn=accounts,dc=local,dc=lan
cn: oepp_hosts
nisDomainName: mgmt.prod.local.lan
objectClass: ipanisnetgroup
objectClass: ipaobject
objectClass: mepManagedEntry
objectClass: ipaAssociation
objectClass: top
nsUniqueId: f834f7a7-f91c11e6-a7d5eda5-d52d2b10

-- 
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] shadow netgroups with wrong domains - sudo problem

[Lukas Slebodnik]

On (17/03/17 10:40), Bob Hinton wrote:
>On 17/03/2017 08:41, Jakub Hrozek wrote:
>> On Fri, Mar 17, 2017 at 06:50:34AM +, Bob Hinton wrote:
>>> 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 ?
>> Did you remove the sssd cache after the migration?
>> rm -f /var/lib/sss/db/*.ldb
>>
>> (please make sure the clients can reach the server or maybe mv the cache
>> instead of rm so you can restore cached credentials if something goes
>> wrong..)
>>
>Hi Jakub,
>
>I've now tried removing the sssd cache on one of the offending servers
>and it's not made any difference.
>
>getent netgroup oepp_hosts
>
>when run from any host enrolled to the new IPA servers, including the
>IPA masters themselves produces the results with "mgmt.prod" included
>and the same thing run on any of the pre-migrated servers that are still
>commissioned produces them without, so I assume that the netgroup domain
>information is coming from the IPA masters rather than the local host.
>
Could you provide content of LDIF from IPA server?
For this netgroup/hostgroup

LS

-- 
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] shadow netgroups with wrong domains - sudo problem

[Bob Hinton]

On 17/03/2017 08:41, Jakub Hrozek wrote:
> On Fri, Mar 17, 2017 at 06:50:34AM +, Bob Hinton wrote:
>> 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 ?
> Did you remove the sssd cache after the migration?
> rm -f /var/lib/sss/db/*.ldb
>
> (please make sure the clients can reach the server or maybe mv the cache
> instead of rm so you can restore cached credentials if something goes
> wrong..)
>
Hi Jakub,

I've now tried removing the sssd cache on one of the offending servers
and it's not made any difference.

getent netgroup oepp_hosts

when run from any host enrolled to the new IPA servers, including the
IPA masters themselves produces the results with "mgmt.prod" included
and the same thing run on any of the pre-migrated servers that are still
commissioned produces them without, so I assume that the netgroup domain
information is coming from the IPA masters rather than the local host.

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

Re: [Freeipa-users] Adjusting nsslapd-cachememsize

[Petr Vobornik]

On 03/17/2017 03:20 AM, Lachlan Musicman wrote:

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.


When you install a first IPA server, run ipa-kra-install, or install a 
replica (before 4.4 replica promotion) you typically write that password.


I.e. in ipa-server-install you provide 2 passwords, one for directory 
manager second for admin user.




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






--
Petr Vobornik

Associate Manager, Engineering, Identity Management
Red Hat, Inc.

--
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] Adjusting nsslapd-cachememsize

[Bob Hinton]

Hi Lachlan,

This is probably a complete hack, but the way I've changed
nsslapd-cachememsize in the past is -

On each ipa replica in turn -

 1. ipactl stop
 2. vim /etc/dirsrv/slapd-DOMAIN/dse.ldif- (where DOMAIN is your
server's domain/realm - not sure which) find and change the value of
nsslapd-cachememsize
 3. ipactl start

This seemed to work in that it made the error messages go away and it
made heavily loaded servers more stable. However, I've not tried this on
a recent version of ipa so it may no longer work or not be needed any more.

Regards

Bob


On 17/03/2017 02:20, Lachlan Musicman wrote:
> 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] shadow netgroups with wrong domains - sudo problem

[Jakub Hrozek]

On Fri, Mar 17, 2017 at 06:50:34AM +, Bob Hinton wrote:
> 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 ?

Did you remove the sssd cache after the migration?
rm -f /var/lib/sss/db/*.ldb

(please make sure the clients can reach the server or maybe mv the cache
instead of rm so you can restore cached credentials if something goes
wrong..)

-- 
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] Slow logins on one ipa client- due to SSS_PAM_ACCT_MGMT

[Jakub Hrozek]

On Thu, Mar 16, 2017 at 08:24:42PM +, Kilborn, Jim wrote:
> 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?

The timestamps from the logs are missing, so it's not clear which call
is taking long. No server lookups should be performed in the account
phase, though, so I can only think of the selinux label setting in
libselinux, which is also done in the account phase to be taking long.

can you try to disable the selinux provider for a test?
selinux_provider=none
btw why is the 'fast' client not running the account phase at all? Is
pam_sss in the account stack in the PAM configuration? Is the
access_provider set to anything else than IPA in the sssd.conf file?

-- 
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

[Jakub Hrozek]

On Fri, Mar 17, 2017 at 08:35:42AM +1100, Lachlan Musicman wrote:
> Which logs do you want from the server?

NSS and domain

-- 
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] Manual Cleanup

[Standa Laznicka]

Hello Ian,

You could do:
`ipa-replica-manage del freeipa-dal.bpt.rocks --force --cleanup`

Then you may need to check again for the master with `ipa-replica-manage 
list`. If it's not there anymore, check whether some RUVs are still in 
place with `ipa-replica-manage list-ruv`.


The last command should get you RUVs on both CA and domain suffixes if 
you're using FreeIPA >= 4.3.2 (hope I got the .z number right). If you 
see that there's some RUVs left for the wrong host, try calling 
`ipa-replica-manage clean-ruv ` which should remove the RUV (no 
matter the suffix - CA or domain - just give it the number and it should 
work given FreeIPA >= 4.3.2 is used).


HTH,
Standa

On 03/16/2017 07:14 PM, Ian Harding wrote:

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 

[Freeipa-users] shadow netgroups with wrong domains - sudo problem

[Bob Hinton]

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