from:"Bob"

On 18/03/2017 19:09, Alexander Bokovoy wrote:
> On la, 18 maalis 2017, Bob Hinton wrote:
>> On 18/03/2017 17:03, Alexander Bokovoy wrote:
>>> On la, 18 maalis 2017, Bob Hinton wrote:
>>>> Hi,
>>>>
>>>> The first IPA master we built was ipa001.local.lan. We have since
>>>> created a number of subdomains of local.lan and have created a
>>>> number of
>>>> replicas. The current configuration has two clusters of IPA replicas -
>>>> ipa001.mgmt.prod.local.lan to ipa003.mgmt.prod.local.lan and
>>>> ipa001.mgmt.paas.local.lan to ipa003.mgmt.paas.local.lan
>>>>
>>>> We've recently commenced migrating some of the existing systems to
>>>> a new
>>>> environment and for various reasons have started with a fresh master -
>>>> ipa001.mgmt.prod.local.lan.
>>>>
>>>> Quite a lot of sudo rules don't work in the new environment. As far
>>>> as I
>>>> can tell this is because the shadow netgroups have a nisdomain of
>>>> mgmt.prod.local.lan instead of local.lan.
>>>>
>>>> I would have thought that the nisdomain should be set to either the
>>>> domain or realm i.e. local.lan rather than seemingly taken from the
>>>> network portion of the first master mgmt.prod.local.lan. Is this
>>>> correct ?
>>>>
>>>> Is there a way to change the default nisdomain ? Rebuilding all the
>>>> new
>>>> IPA masters and migrating all the data again would be a lot of work.
>>> The code that handles 'ipa netgroup-add' defaults to IPA domain as
>>> default NIS domain name. You can change that by explicitly adding
>>> '--nisdomain=specific.nis.domain' to 'ipa netgroup-add'. You can change
>>> it for existing netgroups by specifying --nisdomain option to 'ipa
>>> netgroup-mod'.
>>>
>> Hi Alexander,
>>
>> Thanks for the information. Unfortunately, it's the shadow netgroups
>> created for hostgroups that are the problem. These aren't visible so can
>> I modify them with "ipa netgroup-mod" ? Also the default NIS domain name
>> doesn't match the IPA domain on our system, which is why I'm wondering
>> if we've hit a bug. This is IPA version 4.4.0.
> Got you. No, this is not a bug, you can fix your setup by specifying a
> different nisDomainName in the NGP HGP template definition. This would
> change default nisDomainName for new netgroups. For existing ones you
> would need to go and change nisDomainName attribute manually.
>
> You can do both of these operations with ipa-ldap-updater tool.
>
> 1. Changing default nisDomainName in the NGP HGP template.
>
> First, check what
> nisDomainName value is in the template. Let's assume your domain suffix
> is dc=example,dc=com below. I'll replace it with $DOMAINDN in the output
> for brevity.
>
> -
> # export DOMAINDN='dc=example,dc=com'
> # ldapsearch -H `cat /etc/ipa/default.conf |grep ldap_uri|cut -d' '
> -f3` -b  "cn=NGP HGP Template,cn=Templates,cn=Managed
> Entries,cn=etc,$DOMAINDN"
> SASL/EXTERNAL authentication started
> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> SASL SSF: 0
> # extended LDIF
> #
> # LDAPv3
> # base

Re: [Freeipa-users] default nisdomain appears to be derived from hostname of first master rather than set to domain or realm. Bug ?

On 18/03/2017 17:03, Alexander Bokovoy wrote:
> On la, 18 maalis 2017, Bob Hinton wrote:
>> Hi,
>>
>> The first IPA master we built was ipa001.local.lan. We have since
>> created a number of subdomains of local.lan and have created a number of
>> replicas. The current configuration has two clusters of IPA replicas -
>> ipa001.mgmt.prod.local.lan to ipa003.mgmt.prod.local.lan and
>> ipa001.mgmt.paas.local.lan to ipa003.mgmt.paas.local.lan
>>
>> We've recently commenced migrating some of the existing systems to a new
>> environment and for various reasons have started with a fresh master -
>> ipa001.mgmt.prod.local.lan.
>>
>> Quite a lot of sudo rules don't work in the new environment. As far as I
>> can tell this is because the shadow netgroups have a nisdomain of
>> mgmt.prod.local.lan instead of local.lan.
>>
>> I would have thought that the nisdomain should be set to either the
>> domain or realm i.e. local.lan rather than seemingly taken from the
>> network portion of the first master mgmt.prod.local.lan. Is this
>> correct ?
>>
>> Is there a way to change the default nisdomain ? Rebuilding all the new
>> IPA masters and migrating all the data again would be a lot of work.
> The code that handles 'ipa netgroup-add' defaults to IPA domain as
> default NIS domain name. You can change that by explicitly adding
> '--nisdomain=specific.nis.domain' to 'ipa netgroup-add'. You can change
> it for existing netgroups by specifying --nisdomain option to 'ipa
> netgroup-mod'.
>
Hi Alexander,

Thanks for the information. Unfortunately, it's the shadow netgroups
created for hostgroups that are the problem. These aren't visible so can
I modify them with "ipa netgroup-mod" ? Also the default NIS domain name
doesn't match the IPA domain on our system, which is why I'm wondering
if we've hit a bug. This is IPA version 4.4.0.

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] default nisdomain appears to be derived from hostname of first master rather than set to domain or realm. Bug ?

Hi,

The first IPA master we built was ipa001.local.lan. We have since
created a number of subdomains of local.lan and have created a number of
replicas. The current configuration has two clusters of IPA replicas -
ipa001.mgmt.prod.local.lan to ipa003.mgmt.prod.local.lan and
ipa001.mgmt.paas.local.lan to ipa003.mgmt.paas.local.lan

We've recently commenced migrating some of the existing systems to a new
environment and for various reasons have started with a fresh master -
ipa001.mgmt.prod.local.lan.

Quite a lot of sudo rules don't work in the new environment. As far as I
can tell this is because the shadow netgroups have a nisdomain of
mgmt.prod.local.lan instead of local.lan.

I would have thought that the nisdomain should be set to either the
domain or realm i.e. local.lan rather than seemingly taken from the
network portion of the first master mgmt.prod.local.lan. Is this correct ?

Is there a way to change the default nisdomain ? Rebuilding all the new
IPA masters and migrating all the data again would be a lot of work.

Many thanks

Bob Hinton

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

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,

Having looked into this in more detail and I think the route of the
problem is that the first master created was ipa001.mgmt.prod.local.lan
and therefore mgmt.prod.local.lan seems to have been taken as the
default domain for netgroups even though both the domain and realm were
set as local.lan. In the original configuration the first master was
ipa001.local.lan. It was eventually replaced with
ipa001.mgmt.prod.local.lan via replication but that original base level
seems to have stuck.

Can this base setting of mgmt.prod.local.lan somehow be changed to
local.lan so that newly created netgroups get this as their nisdomain ?

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

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

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

On 17/03/2017 08:41, Jakub Hrozek wrote:
> On Fri, Mar 17, 2017 at 06:50:34AM +0000, 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

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

[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

Re: [Freeipa-users] pki-tomcat failure

2017-01-11 Thread Bob Hinton

On 11/01/2017 13:55, Petr Vobornik wrote:
> On 01/10/2017 09:31 PM, Bob Hinton wrote:
>> Hi,
>>
>> The pki-tomcatd services on our IPA servers seem to have stopped working.
>>
>> This seems to be related to the expiry of several certificates -
>>
>> [root@ipa001 ~]# getcert list | more
>> Number of certificates and requests being tracked: 8.
>> Request ID '20161230150048':
>> status: MONITORING
>> stuck: no
>> key pair storage:
>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
>> cert-pki-ca',token='NSS Certificate DB',pin set
>> certificate:
>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
>> cert-pki-ca',token='NSS Certificate DB'
>> CA: dogtag-ipa-ca-renew-agent
>> issuer: CN=Certificate Authority,O=LOCAL.COM
>> subject: CN=CA Audit,O=LOCAL.COM
>> expires: 2017-01-09 08:21:45 UTC
>> key usage: digitalSignature,nonRepudiation
>> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
>> post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
>> "auditSigningCert cert-pki-ca"
>> track: yes
>> auto-renew: yes
>> Request ID '20161230150049':
>> status: MONITORING
>> stuck: no
>> key pair storage:
>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
>> cert-pki-ca',token='NSS Certificate DB',pin set
>> certificate:
>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
>> cert-pki-ca',token='NSS Certificate DB'
>> CA: dogtag-ipa-ca-renew-agent
>> issuer: CN=Certificate Authority,O=LOCAL.COM
>> subject: CN=OCSP Subsystem,O=LOCAL.COM
>> expires: 2017-01-09 08:21:45 UTC
>> key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
>> eku: id-kp-OCSPSigning
>> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
>> post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
>> "ocspSigningCert cert-pki-ca"
>> track: yes
>> auto-renew: yes
>>
>> These were originally in CA_WORKING state, but I moved the clock back
>> and restarted certmonger to try to renew them.
>
> Certs above have:
>expires: 2017-01-09 08:21:45 UTC
>
> But log has 10/Jan so the log is from the time when certs are expired.
>
> Move time back when all certs reported by `getcert list` are valid.
> Restart IPA. Resubmit all certs which are about to expire. Move time back.
>
Hi Petr,

I had already tried moving the clock back, but unfortunately tomcat-pki
still wouldn't start. I had to temporarily configure it to connect to
LDAP using BasicAuth, as suggested by Adam Tkac. With this done and the
time moved back tomcat-pki started OK and restarting certmonger made it
renew all the certs.

Presumably something was already broken and so certmonger didn't renew
them in the first place.

Thanks

Bob
>>
>> /var/log/pki/pki-tomcat/ca/debug contains
>>
>> [10/Jan/2017:18:35:37][localhost-startStop-1]: makeConnection:
>> errorIfDown true
>> [10/Jan/2017:18:35:37][localhost-startStop-1]:
>> SSLClientCertificateSelectionCB: Setting desired cert nickname to:
>> subsystemCert cert-pki-ca
>> [10/Jan/2017:18:35:37][localhost-startStop-1]: LdapJssSSLSocket: set
>> client auth cert nickname subsystemCert cert-pki-ca
>> [10/Jan/2017:18:35:37][localhost-startStop-1]:
>> SSLClientCertificatSelectionCB: Entering!
>> [10/Jan/2017:18:35:37][localhost-startStop-1]: Candidate cert:
>> caSigningCert cert-pki-ca
>> [10/Jan/2017:18:35:37][localhost-startStop-1]: Candidate cert:
>> Server-Cert cert-pki-ca
>> [10/Jan/2017:18:35:37][localhost-startStop-1]:
>> SSLClientCertificateSelectionCB: returning: null
>> [10/Jan/2017:18:35:37][localhost-startStop-1]: SSL handshake happened
>> Could not connect to LDAP server host ipa001.mgmt.local.com port 636
>> Error netscape.ldap.LDAPException: Authentication failed (48)
>> at
>> com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConnection(LdapBoundConnFactory.java:205)
>> at
>> com.netscape.cmscore.ldapconn.LdapBoundConnFactory.init(LdapBoundConnFactory.java:166)
>> at
>> com.netscape.cmscore.ldapconn.LdapBoundConnFactory.init(LdapBoundConnFactory.java:130)
>> at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:654)
>> at
>> com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:1169)
&

Re: [Freeipa-users] pki-tomcat failed. [SOLVED]

2017-01-10 Thread Bob Hinton

Hi Adam,

With the change to ldap instead of ldaps on the CA master that you
suggested I was able to move the system clock to before the certificate
expiry time then do

ipactl start --ignore-service-failures
systemctl start pki-tomcat@pki-tomcat.service
   then start the pki ca service manually as stated in "systemctl status
pki-tomcat@pki-tomcat.service -l"
service certmonger restart

I then ran "getcert list | more" and waited until all the certificates
had updated

After that "ipactl stop; ipactl start" completed without errors and I
could reenable ntpd and vmware tools timesync.

Finally ipa-certupdate seems to have been needed to propagate the new
certs to the other replicas.

Many thanks

Bob

On 10/01/2017 20:47, Adam Tkac wrote:
> Hello,
>
> we hit similar issue (although due to different conditions - we rotated
> root CA cert and then newly issued certificates were wrongly signed), we
> were also unable to start tomcat. If I remember correctly, we switched dogtag
> to use simple binds instead of TLS to connect to LDAP this way.
>
> 1. systemctl stop pki-tomcatd@pki-tomcat.service
> 2. backup /etc/pki/pki-tomcat/ca/CS.cfg and /etc/pki/pki-tomcat/password.conf
> 3. add directory manager password into password.conf file, it should be line
> like
>
> internaldb=my_directory_manager_password
>
> 4. tune CS.cfg a little, take this diff as an example
>
> +internaldb.ldapauth.authtype=BasicAuth
> +internaldb.ldapauth.bindDN=cn=Directory Manager
> +internaldb.ldapauth.bindPWPrompt=internaldb
> -internaldb.ldapauth.authtype=SslClientAuth
> -internaldb.ldapauth.bindDN=uid=pkidbuser,ou=people,o=ipaca
>  internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca
>  internaldb.ldapconn.cloneReplicationPort=389
>  internaldb.ldapconn.masterReplicationPort=7389
> +internaldb.ldapconn.port=389
> -internaldb.ldapconn.port=636
>  internaldb.ldapconn.replicationSecurity=TLS
> +internaldb.ldapconn.secureConn=false
> -internaldb.ldapconn.secureConn=true
>
> 5. systemctl start pki-tomcatd@pki-tomcat.service
>
> Now tomcat should run correctly and you should be able to resubmit expired
> certs and you can start to experiment with switch dogtag back to TLS auth.
> Hope this helps you.
>
> Regards, Adam
>
> On Tue, Jan 10, 2017 at 07:27:04PM +, Bob Hinton wrote:
>> Hi,
>>
>> The pki-tomcatd services on our IPA servers seem to have stopped working.
>>
>> This seems to be related to the expiry of several certificates -
>>
>> [root@ipa001 ~]# getcert list | more
>> Number of certificates and requests being tracked: 8.
>> Request ID '20161230150048':
>> status: MONITORING
>> stuck: no
>> key pair storage:
>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
>> cert-pki-ca',token='NSS Certificate DB',pin set
>> certificate:
>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
>> cert-pki-ca',token='NSS Certificate DB'
>> CA: dogtag-ipa-ca-renew-agent
>> issuer: CN=Certificate Authority,O=LOCAL.COM
>> subject: CN=CA Audit,O=LOCAL.COM
>> expires: 2017-01-09 08:21:45 UTC
>> key usage: digitalSignature,nonRepudiation
>> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
>> post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
>> "auditSigningCert cert-pki-ca"
>> track: yes
>> auto-renew: yes
>> Request ID '20161230150049':
>> status: MONITORING
>> stuck: no
>> key pair storage:
>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
>> cert-pki-ca',token='NSS Certificate DB',pin set
>> certificate:
>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
>> cert-pki-ca',token='NSS Certificate DB'
>> CA: dogtag-ipa-ca-renew-agent
>> issuer: CN=Certificate Authority,O=LOCAL.COM
>> subject: CN=OCSP Subsystem,O=LOCAL.COM
>> expires: 2017-01-09 08:21:45 UTC
>> key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
>> eku: id-kp-OCSPSigning
>> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
>> post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
>> "ocspSigningCert cert-pki-ca"
>> track: yes
>> auto-renew: yes
>>
>> These were originally in CA_WORKING state, but I moved the clock back
>> and restarted certmonger to try to renew them.
>>
>>
>> /var/log/pki/pki-tomcat/ca/debug contains
>>
>> [10/

[Freeipa-users] pki-tomcat failure

2017-01-10 Thread Bob Hinton

ardWrapper.java:1085)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5318)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5610)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:899)
at
org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133)
at
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156)
at
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:873)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:652)
at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:679)
at
org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1966)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Internal Database Error encountered: Could not connect to LDAP server
host ipa001.mgmt.local.com port 636 Error netscape.ldap.LDAPException:
Authentication failed (48)
at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:676)

The only connection attempt I can find relating to err=48 in the slapd
access log is -


[10/Jan/2017:18:21:08.884446519 +] conn=59668 fd=83 slot=83 SSL
connection from 10.220.6.250 to 10.220.6.250
[10/Jan/2017:18:21:08.898844561 +] conn=59668 TLS1.2 256-bit AES
[10/Jan/2017:18:21:08.917314723 +] conn=59668 op=0 BIND dn=""
method=sasl version=3 mech=EXTERNAL
[10/Jan/2017:18:21:08.919725280 +] conn=59668 op=0 RESULT err=48
tag=97 nentries=0 etime=0
[10/Jan/2017:18:21:09.590236408 +] conn=59637 op=88 EXT
oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop"

We recent upgraded ipa from 4.2 to 4.4 and I wonder if that broke something.

 ipa --version
VERSION: 4.4.0, API_VERSION: 2.213

The /etc/ca.crt cert was originally created on an ipa 3.3 server that no
longer exists, I don't know if that's relevant.

Anyway, I'm stumped on how to fix this so could anyone please help.

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] pki-tomcat failed.

2017-01-10 Thread Bob Hinton

ardWrapper.java:1085)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5318)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5610)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:899)
at
org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133)
at
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156)
at
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:873)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:652)
at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:679)
at
org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1966)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Internal Database Error encountered: Could not connect to LDAP server
host ipa001.mgmt.local.com port 636 Error netscape.ldap.LDAPException:
Authentication failed (48)
at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:676)

The only connection attempt I can find relating to err=48 in the slapd
access log is -


[10/Jan/2017:18:21:08.884446519 +] conn=59668 fd=83 slot=83 SSL
connection from 10.220.6.250 to 10.220.6.250
[10/Jan/2017:18:21:08.898844561 +] conn=59668 TLS1.2 256-bit AES
[10/Jan/2017:18:21:08.917314723 +] conn=59668 op=0 BIND dn=""
method=sasl version=3 mech=EXTERNAL
[10/Jan/2017:18:21:08.919725280 +] conn=59668 op=0 RESULT err=48
tag=97 nentries=0 etime=0
[10/Jan/2017:18:21:09.590236408 +] conn=59637 op=88 EXT
oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop"

We recent upgraded ipa from 4.2 to 4.4 and I wonder if that broke something.

 ipa --version
VERSION: 4.4.0, API_VERSION: 2.213

The /etc/ca.crt cert was originally created on an ipa 3.3 server that no
longer exists, I don't know if that's relevant.

Anyway, I'm stumped on how to fix this so could anyone please help.

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] How do I create a certificate to support LDAPS for an IPA cluster

2016-08-30 Thread Bob Hinton

Hi,

We use IPA to authenticate users for other systems e.g. Rundeck via
LDAP. We have a CNAME for the cluster of IPA masters and could use this
for authentication, but the connection would then be unencrypted. We
therefore use LDAPS, but this currently forces us to a single server in
the cluster so that Rundeck sees a valid SSL certificate. This means
that the authentication fails if that particular IPA master is down.

Is it possible to create a single SSL certificate that would support a
LDAPS connection to any of the IPA masters and, if so then how is this
done ?

Many thanks

Bob Hinton

-- 
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] How to delete a managed group [SOLVED]

2016-08-04 Thread Bob Hinton

On 03/08/2016 14:13, Rob Crittenden wrote:
> Bob Hinton wrote:
>> On 03/08/2016 07:15, Petr Spacek wrote:
>>> On 3.8.2016 00:58, Bob Hinton wrote:
>>>> Hi,
>>>>
>>>> Something went wrong when trying to restore some preserved users so I
>>>> deleted them and then tried to recreate them. This failed with -
>>>>
>>>> ipa: ERROR: Unable to create private group. A group 'X' 
>>>> already exists.
>>>>
>>>> Trying to delete this group produces -
>>>>
>>>> ipa: ERROR: Unable to create private group. A group 'X' already
>>>> exists.
>>>>
>>>> Trying to detach it with
>>>>
>>>> ipa group-detach X
>>>>
>>>> produces
>>>>
>>>> ipa: ERROR: X: group not found
>>>>
>>>> ipa group-show X
>>> I would try
>>> $ ipa group show X --all --raw
>>>
>>> that could show us if there is something interesting like
>>> replication conflict
>>> or so.
>>>
>>> Petr^2 Spacek
>> Hi Petr,
>>
>> This produces ...
>>
>> ipa group-show X --all --raw
>>dn: cn=X,cn=groups,cn=accounts,dc=local,dc=com
>>cn: X
>>description: User private group for X
>>gidnumber: 799830053
>>ipaUniqueID: 3b8e0ec8-58c4-11e6-806d-005056015864
>>mepManagedBy: uid=X,cn=users,cn=accounts,dc=local,dc=com
>>objectClass: posixgroup
>>objectClass: ipaobject
>>objectClass: mepManagedEntry
>>objectClass: top
>>
>> We do have some replication problems at the moment - two recreated
>> replicas currently have two RUVs so this could this be how the user
>> delete completed without the corresponding group?
>
> Not sure. The 389-ds plugin should, by definition, remove the group
> when a user is deleted. I'd be more inclined to believe that the group
> was added and the user not in a replication event.
>
> Removing the group requires an ldapmodify:
>
> % kinit admin
> % ldapmodify -Y GSSAPI
> SASL/GSSAPI authentication started
> SASL username: ad...@example.com
> SASL SSF: 56
> SASL data security layer installed.
> dn: cn=deleteme,cn=groups,cn=accounts,dc=example,dc=com
> changetype: modify
> delete: objectclass
> objectclass: mepManagedEntry
> -
> delete: mepManagedBy
> mepManagedBy: uid=deleteme,cn=users,cn=accounts,dc=example,dc=com
> ^D
> modifying entry "cn=deleteme,cn=groups,cn=accounts,dc=example,dc=com"
>
> % ipa group-del deleteme
> 
> Deleted group "deleteme"
> 
>
> Makes me wonder if the managed entry plugin should allow deletion if
> the other side of the link doesn't exist. I'll investigate this.
>
> rob
> .
>
Hi Rob,

Your procedure detailed above allowed me to delete the old private
groups and then recreate the user accounts.

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] How to delete a managed group

2016-08-03 Thread Bob Hinton

On 03/08/2016 07:15, Petr Spacek wrote:
> On 3.8.2016 00:58, Bob Hinton wrote:
>> Hi,
>>
>> Something went wrong when trying to restore some preserved users so I
>> deleted them and then tried to recreate them. This failed with -
>>
>> ipa: ERROR: Unable to create private group. A group 'X'  already exists.
>>
>> Trying to delete this group produces -
>>
>> ipa: ERROR: Unable to create private group. A group 'X' already exists.
>>
>> Trying to detach it with
>>
>> ipa group-detach X
>>
>> produces
>>
>> ipa: ERROR: X: group not found
>>
>> ipa group-show X
> I would try
> $ ipa group show X --all --raw
>
> that could show us if there is something interesting like replication conflict
> or so.
>
> Petr^2 Spacek
Hi Petr,

This produces ...

ipa group-show X --all --raw
  dn: cn=X,cn=groups,cn=accounts,dc=local,dc=com
  cn: X
  description: User private group for X
  gidnumber: 799830053
  ipaUniqueID: 3b8e0ec8-58c4-11e6-806d-005056015864
  mepManagedBy: uid=X,cn=users,cn=accounts,dc=local,dc=com
  objectClass: posixgroup
  objectClass: ipaobject
  objectClass: mepManagedEntry
  objectClass: top

We do have some replication problems at the moment - two recreated
replicas currently have two RUVs so this could this be how the user
delete completed without the corresponding group?

Thanks

Bob
>
>> displays the group, but "ipa group-find X" doesn't
>>
>> How can get rid of the group so I can recreate the user ?
>>
>> 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] How to delete a managed group

2016-08-02 Thread Bob Hinton

Hi,

Something went wrong when trying to restore some preserved users so I
deleted them and then tried to recreate them. This failed with -

ipa: ERROR: Unable to create private group. A group 'X'  already exists.

Trying to delete this group produces -

ipa: ERROR: Unable to create private group. A group 'X' already exists.

Trying to detach it with

ipa group-detach X

produces

ipa: ERROR: X: group not found

ipa group-show X

displays the group, but "ipa group-find X" doesn't

How can get rid of the group so I can recreate the user ?

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] Struggling to remove redundant RUV records

2016-07-19 Thread Bob Hinton

Hi,

We had to replace a failed replica "ipa003.mgmt.prod.local".
Unfortunately, deleting the old copy prior to creating the replacement
doesn't seem to have worked and we're getting lots of errors like :-

attrlist_replace - attr_replace (nsslapd-referral,
ldap://ipa003.mgmt.prod.local:389 ... failed.

In the dirsrv logs.

One problem is that there are now two RUVs for ipa003.mgmt.prod.local.
How do I identify which is the live one so I can delete the redundant one ?

I'd also like to delete all the old "unable to decode" replicas. I found
a posting with an ldapsearch (see below), but this seems to give numbers
that don't match the replica IDs. Do I need to translate the search
results in some fashion or use a different search ?

Many Thanks

Bob Hinton

-sh-4.2$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.2 (Maipo)

-sh-4.2$ ipa --version
VERSION: 4.2.0, API_VERSION: 2.156

sh-4.2$ sudo ipa-replica-manage list-ruv
Directory Manager password:

unable to decode: {replica 15} 568d15720002000f 568d15720002000f
unable to decode: {replica 13} 568ed0a90001000d 56ebea6b0001000d
unable to decode: {replica 14} 568d16ea000e 56ab57950005000e
ipa002.mgmt.prod.local:389: 17
ipa001.mgmt.paas.local:389: 22
ipa003.mgmt.paas.local:389: 26
ipa002.mgmt.paas.local:389: 24
ipa002.mgmt.paas.local:389: 25
ipa003.mgmt.prod.local:389: 23
ipa003.mgmt.prod.local:389: 18
ipa001.mgmt.prod.local:389: 19
sh-4.2$ !996
sudo ipa-replica-manage clean-ruv 13
Directory Manager password:

unable to decode: {replica 15} 568d15720002000f 568d15720002000f
unable to decode: {replica 13} 568ed0a90001000d 56ebea6b0001000d
unable to decode: {replica 14} 568d16ea000e 56ab57950005000e
Replica ID 13 not found
sh-4.2$ !1000
ldapsearch -D "cn=Directory Manager" -W -h ipa003.mgmt.prod.local -b
"o=ipaca"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
| grep "nsds50ruv\|nsDS5ReplicaId"
Enter LDAP Password:
nsDS5ReplicaId: 1485
nsds50ruv: {replicageneration} 54be65640060
nsds50ruv: {replica 1485 ldap://ipa003.mgmt.prod.local:389} 5787b6e
nsds50ruv: {replica 1395 ldap://ipa001.mgmt.prod.local:389} 567ab7a
nsds50ruv: {replica 1490 ldap://ipa001.mgmt.paas.local:389} 5787aef
nsds50ruv: {replica 1495 ldap://ipa001.mgmt.paas.local:389} 578660e
nsds50ruv: {replica 1280 ldap://ipa002.mgmt.prod.local:389} 567949c
nsds50ruv: {replica 71 ldap://ipa4-03.local:389} 5617ba4d004700
nsds50ruv: {replica 1285 ldap://ipa001.mgmt.prod.local:389} 567804c
nsds50ruv: {replica 1290 ldap://ipa4-02.local:389} 561bb7bc050a
nsds50ruv: {replica 1295 ldap://ipa4-01.local:389} 561ba643050f
nsds50ruv: {replica 96 ldap://ipa0001-01.local:7389} 54be656e00
nsds50ruv: {replica 76 ldap://ipa4-rep.local:389} 56142cde004c0
nsds50ruv: {replica 81 ldap://ipa0001-03.local:7389} 54c25ac600
nsds50ruv: {replica 86 ldap://ipa0001-02.local:7389} 54c12c1d00
nsds50ruv: {replica 91 ldap://ipa0001-03.local:7389} 54bf475b00
nsds50ruv: {replica 97 ldap://ipa0001-02.local:7389} 54be656b00
nsds50ruv: {replica 1096 ldap://ipa3-rhel6.local:7389} 560d7d77
nsds50ruv: {replica 1196 ldap://ip4-rhel7.local:389} 56137c3104
nsds50ruv: {replica 1191 ldap://ipa4-rhel7.local:389} 5613a7ac0
nsds50ruv: {replica 1275 ldap://ipa003.mgmt.prod.local:389} 56797be
nsds50ruv: {replica 1390 ldap://ipa002.mgmt.paas.local:389} 5787bb9
nsds50ruv: {replica 1595 ldap://ipa002.mgmt.paas.local:389} 5787db0
nsds50ruv: {replica 1590 ldap://ipa003.mgmt.paas.local:389} 5787e0f



-- 
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] named-pkcs11 fails on new ipa replica

2016-07-14 Thread Bob Hinton

Hi,

We are trying to create a new replica on RHEL 7.2

This completes but named-pkcs11 fails to start -

 systemctl status named-pkcs11.service
● named-pkcs11.service - Berkeley Internet Name Domain (DNS) with native
PKCS#11
   Loaded: loaded (/usr/lib/systemd/system/named-pkcs11.service;
disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2016-07-13 18:38:15 BST;
51min ago
  Process: 25913 ExecStart=/usr/sbin/named-pkcs11 -u named $OPTIONS
(code=exited, status=1/FAILURE)
  Process: 25910 ExecStartPre=/bin/bash -c if [ !
"$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z
/etc/named.conf; else echo "Checking of zone files is disabled"; fi
(code=exited, status=0/SUCCESS)

Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: corporation. 
Support and training for BIND 9 are
Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: available at
https://www.isc.org/support
Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]:

Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: adjusted limit on
open files from 4096 to 1048576
Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: found 1 CPU,
using 1 worker thread
Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: using 1 UDP
listener per interface
Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: named-pkcs11.service:
control process exited, code=exited status=1
Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: Failed to start Berkeley
Internet Name Domain (DNS) with native PKCS#11.
Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: Unit named-pkcs11.service
entered failed state.
Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: named-pkcs11.service failed.

# /usr/sbin/named-pkcs11 -d 9 -g
13-Jul-2016 19:31:01.283 starting BIND 9.9.4-RedHat-9.9.4-29.el7_2.1 -d 9 -g
13-Jul-2016 19:31:01.283 built with '--build=x86_64-redhat-linux-gnu'
'--host=x86_64-redhat-linux-gnu' '--program-prefix='
'--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64'
'--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib'
'--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool'
'--localstatedir=/var' '--enable-threads' '--enable-ipv6'
'--enable-filter-' '--enable-rrl' '--with-pic' '--disable-static'
'--disable-openssl-version-check' '--enable-exportlib'
'--with-export-libdir=/usr/lib64'
'--with-export-includedir=/usr/include'
'--includedir=/usr/include/bind9' '--enable-native-pkcs11'
'--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes'
'--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes'
'--with-dlz-filesystem=yes' '--with-dlz-bdb=yes' '--with-gssapi=yes'
'--disable-isc-spnego' '--enable-fixed-rrset'
'--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets'
'build_alias=x86_64-redhat-linux-gnu'
'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic'
'LDFLAGS=-Wl,-z,relro ' 'CPPFLAGS= -DDIG_SIGCHASE'
13-Jul-2016 19:31:01.283

13-Jul-2016 19:31:01.284 BIND 9 is maintained by Internet Systems
Consortium,
13-Jul-2016 19:31:01.284 Inc. (ISC), a non-profit 501(c)(3) public-benefit
13-Jul-2016 19:31:01.284 corporation.  Support and training for BIND 9 are
13-Jul-2016 19:31:01.284 available at https://www.isc.org/support
13-Jul-2016 19:31:01.284

13-Jul-2016 19:31:01.284 adjusted limit on open files from 4096 to 1048576
13-Jul-2016 19:31:01.284 found 1 CPU, using 1 worker thread
13-Jul-2016 19:31:01.284 using 1 UDP listener per interface
13-Jul-2016 19:31:01.284 using up to 4096 sockets
13-Jul-2016 19:31:01.284 Registering DLZ_dlopen driver
13-Jul-2016 19:31:01.284 Registering SDLZ driver 'dlopen'
13-Jul-2016 19:31:01.284 Registering DLZ driver 'dlopen'
13-Jul-2016 19:31:01.287 initializing DST: PKCS#11 initialization failed
13-Jul-2016 19:31:01.287 exiting (due to fatal error)

# tail -2 /var/log

Jul 13 19:31:01 ipa001.mgmt.local named-pkcs11[27088]:
ObjectStore.cpp(59): Failed to enumerate object store in
/var/lib/softhsm/tokens/

Jul 13 19:31:01 ipa001.mgmt.local named-pkcs11[27088]: SoftHSM.cpp(456):
Could not load the object store

I've tried "ipa-server-upgrade" and

mv /var/lib/ipa/dnssec/tokens /var/lib/ipa/dnssec/tokens-OLD

ipa-dns-install

But I haven't managed to fix it.

Using "ipactl start -f" means the rest of the ipa services seem to work
properly, but without named.

Is there a way to fix the named issue or is it much simpler to
disconnect the replica, uninstall it and start again ?

Thanks

Bob Hinton

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.re

Re: [Freeipa-users] named-pkcs11 fails to start on new replica [SOLVED]

2016-07-14 Thread Bob Hinton

On 14/07/2016 08:39, Martin Babinsky wrote:
> On 07/13/2016 09:56 PM, Bob Hinton wrote:
>> Hi,
>>
>> We are trying to create a new replica on RHEL 7.2
>>
>> This completes but named-pkcs11 fails to start -
>>
>>  systemctl status named-pkcs11.service
>> ● named-pkcs11.service - Berkeley Internet Name Domain (DNS) with native
>> PKCS#11
>>Loaded: loaded (/usr/lib/systemd/system/named-pkcs11.service;
>> disabled; vendor preset: disabled)
>>Active: failed (Result: exit-code) since Wed 2016-07-13 18:38:15 BST;
>> 51min ago
>>   Process: 25913 ExecStart=/usr/sbin/named-pkcs11 -u named $OPTIONS
>> (code=exited, status=1/FAILURE)
>>   Process: 25910 ExecStartPre=/bin/bash -c if [ !
>> "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z
>> /etc/named.conf; else echo "Checking of zone files is disabled"; fi
>> (code=exited, status=0/SUCCESS)
>>
>> Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: corporation.
>> Support and training for BIND 9 are
>> Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: available at
>> https://www.isc.org/support
>> Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]:
>> 
>> Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: adjusted limit on
>> open files from 4096 to 1048576
>> Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: found 1 CPU,
>> using 1 worker thread
>> Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: using 1 UDP
>> listener per interface
>> Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: named-pkcs11.service:
>> control process exited, code=exited status=1
>> Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: Failed to start Berkeley
>> Internet Name Domain (DNS) with native PKCS#11.
>> Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: Unit named-pkcs11.service
>> entered failed state.
>> Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: named-pkcs11.service
>> failed.
>>
>> # /usr/sbin/named-pkcs11 -d 9 -g
>> 13-Jul-2016 19:31:01.283 starting BIND 9.9.4-RedHat-9.9.4-29.el7_2.1
>> -d 9 -g
>> 13-Jul-2016 19:31:01.283 built with '--build=x86_64-redhat-linux-gnu'
>> '--host=x86_64-redhat-linux-gnu' '--program-prefix='
>> '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr'
>> '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
>> '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64'
>> '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib'
>> '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool'
>> '--localstatedir=/var' '--enable-threads' '--enable-ipv6'
>> '--enable-filter-' '--enable-rrl' '--with-pic' '--disable-static'
>> '--disable-openssl-version-check' '--enable-exportlib'
>> '--with-export-libdir=/usr/lib64'
>> '--with-export-includedir=/usr/include'
>> '--includedir=/usr/include/bind9' '--enable-native-pkcs11'
>> '--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes'
>> '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes'
>> '--with-dlz-filesystem=yes' '--with-dlz-bdb=yes' '--with-gssapi=yes'
>> '--disable-isc-spnego' '--enable-fixed-rrset'
>> '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets'
>> 'build_alias=x86_64-redhat-linux-gnu'
>> 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall
>> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
>> --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic'
>> 'LDFLAGS=-Wl,-z,relro ' 'CPPFLAGS= -DDIG_SIGCHASE'
>> 13-Jul-2016 19:31:01.283
>> 
>> 13-Jul-2016 19:31:01.284 BIND 9 is maintained by Internet Systems
>> Consortium,
>> 13-Jul-2016 19:31:01.284 Inc. (ISC), a non-profit 501(c)(3)
>> public-benefit
>> 13-Jul-2016 19:31:01.284 corporation.  Support and training for BIND
>> 9 are
>> 13-Jul-2016 19:31:01.284 available at https://www.isc.org/support
>> 13-Jul-2016 19:31:01.284
>> 
>> 13-Jul-2016 19:31:01.284 adjusted limit on open files from 4096 to
>> 1048576
>> 13-Jul-2016 19:31:01.284 found 1 CPU, using 1 worker thread
>> 13-Jul-2016 19:31:01.284 using 1 UDP listener per interface
>> 13-Jul-2016 19:31:01.284 using up to 4096 sockets
>> 13-Jul-2016 19:31:01.284 Registering DLZ_dlopen driver
>> 13-Jul-2016 19:31:01.284 Registering SDLZ driver 'dlopen'
>> 13-Jul-2016 19:31:01.284 Registering DLZ driver 'dlopen'
>> 13-Jul-2016 19:31:01.

[Freeipa-users] named-pkcs11 fails to start on new replica

2016-07-13 Thread Bob Hinton

Hi,

We are trying to create a new replica on RHEL 7.2

This completes but named-pkcs11 fails to start -

 systemctl status named-pkcs11.service
● named-pkcs11.service - Berkeley Internet Name Domain (DNS) with native
PKCS#11
   Loaded: loaded (/usr/lib/systemd/system/named-pkcs11.service;
disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2016-07-13 18:38:15 BST;
51min ago
  Process: 25913 ExecStart=/usr/sbin/named-pkcs11 -u named $OPTIONS
(code=exited, status=1/FAILURE)
  Process: 25910 ExecStartPre=/bin/bash -c if [ !
"$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z
/etc/named.conf; else echo "Checking of zone files is disabled"; fi
(code=exited, status=0/SUCCESS)

Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: corporation. 
Support and training for BIND 9 are
Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: available at
https://www.isc.org/support
Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]:

Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: adjusted limit on
open files from 4096 to 1048576
Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: found 1 CPU,
using 1 worker thread
Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: using 1 UDP
listener per interface
Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: named-pkcs11.service:
control process exited, code=exited status=1
Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: Failed to start Berkeley
Internet Name Domain (DNS) with native PKCS#11.
Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: Unit named-pkcs11.service
entered failed state.
Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: named-pkcs11.service failed.

# /usr/sbin/named-pkcs11 -d 9 -g
13-Jul-2016 19:31:01.283 starting BIND 9.9.4-RedHat-9.9.4-29.el7_2.1 -d 9 -g
13-Jul-2016 19:31:01.283 built with '--build=x86_64-redhat-linux-gnu'
'--host=x86_64-redhat-linux-gnu' '--program-prefix='
'--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64'
'--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib'
'--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool'
'--localstatedir=/var' '--enable-threads' '--enable-ipv6'
'--enable-filter-' '--enable-rrl' '--with-pic' '--disable-static'
'--disable-openssl-version-check' '--enable-exportlib'
'--with-export-libdir=/usr/lib64'
'--with-export-includedir=/usr/include'
'--includedir=/usr/include/bind9' '--enable-native-pkcs11'
'--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes'
'--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes'
'--with-dlz-filesystem=yes' '--with-dlz-bdb=yes' '--with-gssapi=yes'
'--disable-isc-spnego' '--enable-fixed-rrset'
'--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets'
'build_alias=x86_64-redhat-linux-gnu'
'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic'
'LDFLAGS=-Wl,-z,relro ' 'CPPFLAGS= -DDIG_SIGCHASE'
13-Jul-2016 19:31:01.283

13-Jul-2016 19:31:01.284 BIND 9 is maintained by Internet Systems
Consortium,
13-Jul-2016 19:31:01.284 Inc. (ISC), a non-profit 501(c)(3) public-benefit
13-Jul-2016 19:31:01.284 corporation.  Support and training for BIND 9 are
13-Jul-2016 19:31:01.284 available at https://www.isc.org/support
13-Jul-2016 19:31:01.284

13-Jul-2016 19:31:01.284 adjusted limit on open files from 4096 to 1048576
13-Jul-2016 19:31:01.284 found 1 CPU, using 1 worker thread
13-Jul-2016 19:31:01.284 using 1 UDP listener per interface
13-Jul-2016 19:31:01.284 using up to 4096 sockets
13-Jul-2016 19:31:01.284 Registering DLZ_dlopen driver
13-Jul-2016 19:31:01.284 Registering SDLZ driver 'dlopen'
13-Jul-2016 19:31:01.284 Registering DLZ driver 'dlopen'
13-Jul-2016 19:31:01.287 initializing DST: PKCS#11 initialization failed
13-Jul-2016 19:31:01.287 exiting (due to fatal error)

# tail -2 /var/log

Jul 13 19:31:01 ipa001.mgmt.local named-pkcs11[27088]:
ObjectStore.cpp(59): Failed to enumerate object store in
/var/lib/softhsm/tokens/

Jul 13 19:31:01 ipa001.mgmt.local named-pkcs11[27088]: SoftHSM.cpp(456):
Could not load the object store

I've tried "ipa-server-upgrade" and

mv /var/lib/ipa/dnssec/tokens /var/lib/ipa/dnssec/tokens-OLD

ipa-dns-install

But I haven't managed to fix it.

Using "ipactl start -f" means the rest of the ipa services seem to work
properly, but without named.

Is there a way to fix the named issue or is it much simpler to
disconnect the replica, uninstall it and start again ?

Thanks

Bob Hinton

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.re

Re: [Freeipa-users] Adding groupOfUniqueNames to all freeipa replicas for Zenoss LDAP authentication

2016-05-27 Thread Bob Hinton

Hi Martin,

On 27/05/2016 14:01, Martin Kosek wrote:
> On 05/25/2016 09:51 PM, Bob Hinton wrote:
>> Hello,
>>
>> We are trying to get Zenoss login authentication to use freeipa over
>> LDAP. Group mappings don't currently work and we think this is because
>> Zenoss requires the groupOfUniqueNames object class.
>>
>> I managed to add the object class to a test VM using
>> vsphere_groupmod.ldif taken from
>> http://www.freeipa.org/page/HowTo/vsphere5_integration -
>>
>> content of vsphere_groupmod.ldif -
>>
>> dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config
>> changetype: modify
>> add: schema-compat-entry-attribute
>> schema-compat-entry-attribute: objectclass=groupOfUniqueNames
>> -
>> add: schema-compat-entry-attribute
>> schema-compat-entry-attribute:
>> uniqueMember=%mregsub("%{member}","^(.*)accounts(.*)","%1compat%2")
>> -
>>
>> apply with -
>>
>> ldapmodify -x -D "cn=Directory Manager" -f vsphere_groupmod.ldif -W
>>
>> However, the following command seemed to freeze -
>>
>> ipa permission-mod "System: Read Group Compat Tree" --includedattrs
>> uniquemember
>>
>> and I had to kill it then subsequent ldapsearch commands froze.
> That's... strange. Looks like a DS bug.
I tried this on one of the three live servers after using ipa-backup on
each of them and it completed without hanging so this suggests a problem
with my test VM rather than a bug.

>
>> Rebooting the VM seemed to fix things and the groupOfUniqueNames object
>> class appeared in the schema.
>>
>> I'd like to apply this to our live system which uses a master and two
>> replicas running  IPA v4.2.0 on RHEL 7.2.
>>
>> Do I need to make the same change to all three servers ?
> Changes in cn=config needs to be done on all servers as the tree is not
> replicated. Normal permission changes are replicated (unless the permission is
> about cn=config tree).
Yes. I've now spotted that the change is confined to the single live
server. I'll apply it to the other two when we've got the connectivity
with Zenoss working.
>> Can I leave the
>> replicas connected or do I need to break the replication and
>> re-establish it?
> I do not see reason why you would need to break the replication between 
> replicas.
>
>> Do I need the "ipa permission-mod" if so then how do I
>> avoid it freezing ?
> I think the freeze is a bug, I would try reproducing with the latest and
> greatest 389-ds-base (I do not know what version you are using), the bug may 
> be
> already fixed (there were some bugs fixed).
My test VM is quite old, since it didn't happen on the live server and
that is more up to date, it suggests either a bug that has been fixed or
a problem with the test VM.

>
> And yes, the command is needed, so that the new attribute is allowed to be 
> served.
>
> HTH,
> Martin
> .
>
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] Adding groupOfUniqueNames to all freeipa replicas for Zenoss LDAP authentication

2016-05-25 Thread Bob Hinton

Hello,

We are trying to get Zenoss login authentication to use freeipa over
LDAP. Group mappings don't currently work and we think this is because
Zenoss requires the groupOfUniqueNames object class.

I managed to add the object class to a test VM using
vsphere_groupmod.ldif taken from
http://www.freeipa.org/page/HowTo/vsphere5_integration -

content of vsphere_groupmod.ldif -

dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config
changetype: modify
add: schema-compat-entry-attribute
schema-compat-entry-attribute: objectclass=groupOfUniqueNames
-
add: schema-compat-entry-attribute
schema-compat-entry-attribute:
uniqueMember=%mregsub("%{member}","^(.*)accounts(.*)","%1compat%2")
-

apply with -

ldapmodify -x -D "cn=Directory Manager" -f vsphere_groupmod.ldif -W

However, the following command seemed to freeze -

ipa permission-mod "System: Read Group Compat Tree" --includedattrs
uniquemember

and I had to kill it then subsequent ldapsearch commands froze.

Rebooting the VM seemed to fix things and the groupOfUniqueNames object
class appeared in the schema.

I'd like to apply this to our live system which uses a master and two
replicas running  IPA v4.2.0 on RHEL 7.2.

Do I need to make the same change to all three servers ? Can I leave the
replicas connected or do I need to break the replication and
re-establish it? Do I need the "ipa permission-mod" if so then how do I
avoid it freezing ?

Many thanks

Bob Hinton

-- 
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] Tracking Login Times

2016-03-21 Thread Bob

We currently have 18 master ODSEE servers that we use to provide
authentication services to both Redhat, SuSE, and Solaris systems. We
are looking to add IPA servers to environment.

We have a requirement to track time of last authentication.  With
ODSEE, time of last authentication tracking is enabled with this:


*dsconf set-server-prop pwd-keep-last-auth-time-enabled:on*

Looking at the Redhat DS 9 documentation, I see an account policy plug-in:


cn=Account Policy Plugin,cn=plugins,cn=config

Looking the freeipa.org pages on the server plugins, I do not see the
account policy plugin listed.
http://www.freeipa.org/page/Directory_Server

Looking in the directory DT of a "VERSION: 4.2.0, API_VERSION: 2.156"
installed on Redhat 7, I do see the account policy plugin in the
config tree.


Is the use of this account policy plugin supported with IPA? Should it work?

Thanks,

Bob Harvey
-- 
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] Cannot add password policy SOLVED

2016-03-10 Thread Bob Hinton

On 09/03/2016 22:14, Rob Crittenden wrote:
> Bob Hinton wrote:
>> Hi,
>>
>> I've been trying to add a password policy for an existing user group
>> called "services" in IPA version 4.2.0.
>>
>> ipa pwpolicy-add services
>> ipa: ERROR: entry with name "services" already exists
>>
>> ipa pwpolicy-show services
>> ipa: ERROR: services: password policy not found
>>
>> ipa pwpolicy-del services
>> ipa: ERROR: services: password policy not found
>>
>> ipa pwpolicy-mod services
>> ipa: ERROR: services: password policy not found
>>
>> ipa pwpolicy-find
>> doesn't list it.
>>
>> As an experiment I've tried to add additional pwpolicy entries. If these
>> fail due to insufficient privileges then I get the same symptoms, so
>> it's possible that this is what happened with the services pwpolicy.
>>
>> How do I correct this situation?
>>
>> Many thanks
> I'd use ldapsearch to narrow things down. A group-based password policy
> consists of two entries so I'd look in both:
>
> $ kinit admin
> $ ldapsearch -Y GSSAPI -b cn=costemplates,cn=accounts,dc=example,dc=com
> $ ldapsearch -Y GSSAPI -b cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com
> '(objectclass=krbPwdPolicy)'
>
> There could, for example, be a replication conflict entry.
>
> rob
> .
>
Hi Rob,

The culprit turned-out to be a "cn=costemplates,cn=accounts,..." record.
Attempting to create a pwpolicy that failed with a permissions error
created a costemplates record, but not the corresponding
"cn=DOMAIN,cn=kerberos,..." record.

After removing the offending record with ldapdelete I could create the
pwpolicy entry.

Many thanks

Bob Hinton

-- 
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 rules not applying to Solaris clients

2015-08-15 Thread Bob

For Solaris we are using the pam_list module to control which LDAP users
can have system access. The pam_list module allow netgroups to be listed in
a user.allow file.

On Sat, Aug 15, 2015 at 1:05 PM, Natxo Asenjo natxo.ase...@gmail.com
wrote:



 On Sat, Aug 15, 2015 at 5:24 PM, Rob Crittenden rcrit...@redhat.com
 wrote:

 sipazzo wrote:


 and my users are able to authenticate to the directory but the hbac
 rules are not being applied. Any user whether given access or not can
 login to the Solaris systems. The allow-all rule has been disabled, my
 nsswitch.conf file looks good and I have tried different configs of
 pam.d, including the provided example to try to resolve the issue. Am I
 missing some steps?


 HBAC enforcement is provided by sssd so doesn't work in Solaris.


 one might try using solaris' RBAC system:


 http://www.oracle.com/technetwork/systems/security/custom-roles-rbac-jsp-140865.html

 You would have to distribute your changes to all solaris systems.

 There is a RBAC ldap schema
 http://docs.oracle.com/cd/E19455-01/806-5580/6jej518q5/index.html for
 solaris, but I have never tried using it with freeipa.

 --
 Groeten,
 natxo

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

[Freeipa-users] ssh known hosts gets recreated on client

Hello,

If I uninstall the ipa client with ipa-client-install --uninstall then
reinstall it to the same ipa master then most functions work fine.
However, if I attempt to ssh from the client to the master then I get.

@@@
@WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
86:c1:d7:96:8d:a3:b6:54:69:7c:cf:79:55:b3:14:c1.
Please contact your system administrator.
Add correct host key in /home/gbob/.ssh/known_hosts to get rid of this
message.
Offending key in /var/lib/sss/pubconf/known_hosts:1
RSA host key for ipa004.jackland.co.uk has changed and you have
requested strict checking.
Host key verification failed.

I've tried stopping the sssd service on the client, removing
/var/lib/sss/pubconf/known_hosts and /var/lib/sss/db/* then restarting
sssd, but /var/lib/sss/pubconf just gets recreated with the old contents
and I get the same error (it seems odd that it's reporting that the host
key of the master has changed when it's the client that has been
reinstalled). How do I clear-out the client's knowledge of the old host
keys?

In this case I'm using ipa-client v3.0.0 on RHEL6.6

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] ssh known hosts gets recreated on client

The /home/USER/.ssh/known_hosts file doesn't exist. It's
/var/lib/sss/pubconf/known_hosts that's the problem.

If the offending line is deleted from this file or this file is deleted
completely then it's automatically replaced and the same error occurs.

On 10/06/2015 13:55, Cory Carlton wrote:
 I feel this is a User ssh file issue not a sssd when sshing. 
 the client is seeing its a different key exchange with the same IP it
 once knew about, the known_hosts file on the client machine (and user)
 in the .ssh folder need to be updated or wiped clean.

 If you edit on the client machine /home/USER/.ssh/known_hosts delete
 the IP line.

 On Wed, Jun 10, 2015 at 5:33 AM, Bob Hinton b...@jackland.demon.co.uk
 mailto:b...@jackland.demon.co.uk wrote:

 Hello,

 If I uninstall the ipa client with ipa-client-install
 --uninstall then
 reinstall it to the same ipa master then most functions work fine.
 However, if I attempt to ssh from the client to the master then I get.

 @@@
 @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
 @@@
 IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
 Someone could be eavesdropping on you right now (man-in-the-middle
 attack)!
 It is also possible that the RSA host key has just been changed.
 The fingerprint for the RSA key sent by the remote host is
 86:c1:d7:96:8d:a3:b6:54:69:7c:cf:79:55:b3:14:c1.
 Please contact your system administrator.
 Add correct host key in /home/gbob/.ssh/known_hosts to get rid of this
 message.
 Offending key in /var/lib/sss/pubconf/known_hosts:1
 RSA host key for ipa004.jackland.co.uk
 http://ipa004.jackland.co.uk has changed and you have
 requested strict checking.
 Host key verification failed.

 I've tried stopping the sssd service on the client, removing
 /var/lib/sss/pubconf/known_hosts and /var/lib/sss/db/* then restarting
 sssd, but /var/lib/sss/pubconf just gets recreated with the old
 contents
 and I get the same error (it seems odd that it's reporting that
 the host
 key of the master has changed when it's the client that has been
 reinstalled). How do I clear-out the client's knowledge of the old
 host
 keys?

 In this case I'm using ipa-client v3.0.0 on RHEL6.6

 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



-- 
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] ssh known hosts gets recreated on client

On 10/06/2015 14:37, Lukas Slebodnik wrote:
On (10/06/15 11:33), Bob Hinton wrote:
Hello,

If I uninstall the ipa client with ipa-client-install --uninstall then
reinstall it to the same ipa master then most functions work fine.
However, if I attempt to ssh from the client to the master then I get.

@@@
@WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
86:c1:d7:96:8d:a3:b6:54:69:7c:cf:79:55:b3:14:c1.
Please contact your system administrator.
Add correct host key in /home/gbob/.ssh/known_hosts to get rid of this
message.
Offending key in /var/lib/sss/pubconf/known_hosts:1
RSA host key for ipa004.jackland.co.uk has changed and you have
requested strict checking.
Host key verification failed.

I've tried stopping the sssd service on the client, removing
/var/lib/sss/pubconf/known_hosts and /var/lib/sss/db/* then restarting
sssd, but /var/lib/sss/pubconf just gets recreated with the old contents
and I get the same error (it seems odd that it's reporting that the host
key of the master has changed when it's the client that has been
reinstalled). How do I clear-out the client's knowledge of the old host
keys?

In this case I'm using ipa-client v3.0.0 on RHEL6.6

You removed /var/lib/sss/pubconf/known_hosts
and also sssd cache, but you still have problem after restarting sssd.

So the only explanation is that wrong host public key is stored in FreeIPA.
Could you try to check host public key with ldapsearch in FreeIPA.
I think you wold need to do it as an admin.

LS
.

The two rsa keys look like they're the same (see below) though the
finger-prints are evidently different. I copied and pasted the two keys
into files and ran diff over these to prove that they match.

I can actually fix the problem by copying the ipa master host keys to a
file, removing them with

ipa host-mod ipa004.jackland.co.uk --sshpubkey=''

then I can ssh from the client to the master without the error. I can
finally restore the keys from the file using the ipa host-mod command
again and all is well. So this looks like a long-winded way of clearing
some sort of cache of the key finger-print on the client. It would just
be nice to know if there's a more direct way of doing this. Also I know
this works for one client, but it would be a pain to have to go through
this procedure for lots of them.

Thanks

Bob

-sh-4.2$ ipa host-show ipa004.jackland.co.uk --all
dn:
fqdn=ipa004.jackland.co.uk,cn=computers,cn=accounts,dc=jackland,dc=co,dc=uk
Host name: ipa004.jackland.co.uk
Principal name: host/ipa004.jackland.co...@jackland.co.uk
SSH public key: ssh-rsa

B3NzaC1yc2EDAQABAAABAQClPcH8nnghnG3+knwkdg70I106jxO/zIeKggF71C4OHLCu0MJ/loEOcySZ2WH5YPWzRhX1LVN9FyDUKiOc3SNKnjpxjPsJXxk7r77X99jPmk+1QBgYGpn4yrYw/ebEAQLSjHGK86KfNvIbG2RSbNn6uQzC/mciXLEO+7lQ6Vq+DE3Du7+2iuyC2qKeNA9VVzc1NLm0phHT5nOKHpUZ3208GK1vn6r/5YiPmPy5zh8cGmedRft2Fc/J0rOlw5zvwW6kKYZldLvBK7xD2Pm3i2fs38nkH1JA3t83/FXXR/S/F7cY9aI1J/s/UuzawYmeBFXhrbexsUJicY7sS4LqtfBl,
ssh-ed25519
C3NzaC1lZDI1NTE5ILt/SPXhj9izWvjQv5ChWozlOgqRzmSFMZkVj4amRGh/,
ecdsa-sha2-nistp256

E2VjZHNhLXNoYTItbmlzdHAyNTYIbmlzdHAyNTYAAABBBM4R+8D6KCGntBbpGhwDzgH7YJt0xw1Ze21NH+rlsfnoLFStuM7T46/T1L2b2II8hwCmu6dt7F+NSd4YXUpk0/M=
Requires pre-authentication: True
Trusted for delegation: False
Password: False
Keytab: True
Managed by: ipa004.jackland.co.uk
Managing: ipa004.jackland.co.uk
SSH public key fingerprint:
DA:92:FD:52:AE:C2:65:00:9A:F6:0B:AA:20:51:8E:04 (ssh-rsa),

53:79:39:CE:D8:13:23:D2:3C:2C:8E:E4:56:7E:41:76 (ssh-ed25519),

56:28:C4:62:3F:64:18:5D:EC:B9:E0:1F:8B:48:EA:0B (ecdsa-sha2-nistp256)
cn: ipa004.jackland.co.uk
ipauniqueid: 0ffd1566-fd61-11e4-b868-000c29f1a817
krblastpwdchange: 20150518132324Z
objectclass: ipaSshGroupOfPubKeys, ipaobject, krbprincipal, nshost,
top, ipaservice, pkiuser, ipahost,
krbticketpolicyaux, krbprincipalaux, ipasshhost
serverhostname: ipa004
-sh-4.2$

-sh-4.1$ ssh ipa004.jackland.co.uk
@@@
@WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
86:c1:d7:96:8d:a3:b6:54:69:7c:cf:79:55:b3:14:c1.
Please contact your system administrator.
Add correct

Re: [Freeipa-users] ssh known hosts gets recreated on client