Re: [Freeipa-users] SUDO and group lookup in AD trust

[Troels Hansen]

Yes and no

Have tried setting it to both true and false, but doesn't make a huge 
difference.

Current result with "use_fully_qualified_names = false"

LDAP search from sssd_sudo.log shows SSSD finding a sudo rule...

(Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] 
(0x0200): Searching sysdb with 
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=drext...@net.dr.dk)(sudoUser=#1349938498)
...
(sudoUser=%domain_users)(sudoUser=+*)))]
(Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sort_sudo_rules] (0x0400): Sorting 
rules with higher-wins logic
(Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] 
(0x0400): Returning 1 rules for [drext...@net.dr.dk]

SSSD cache shows the sudo rule:

# ldbsearch -H /var/lib/sss/db/cache_linux.dr.dk.ldb -b cn=sysdb 
'(objectClass=sudoRule)'
asq: Unable to register control with rootdse!
# record 1
dn: name=guffe,cn=sudorules,cn=custom,cn=linux.dr.dk,cn=sysdb
cn: guffe
dataExpireTimestamp: 1472110940
entryUSN: 325878
name: guffe
objectClass: sudoRule
originalDN: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk
sudoCommand: /usr/bin/cat /var/log/messages
sudoHost: ALL
sudoRunAsGroup: ALL
sudoRunAsUser: ALL
sudoUser: %domain_users
distinguishedName: name=guffe,cn=sudorules,cn=custom,cn=linux.dr.dk,cn=sysdb

But still sudo debug log says:

Aug 25 08:29:55 sudo[2392] -> user_in_group @ ./pwutil.c:940
Aug 25 08:29:55 sudo[2392] -> sudo_get_grlist @ ./pwutil.c:877
Aug 25 08:29:55 sudo[2392] -> rbfind @ ./redblack.c:273
Aug 25 08:29:55 sudo[2392] <- rbfind @ ./redblack.c:277 := 0x7f877f45d1d0
Aug 25 08:29:55 sudo[2392] <- sudo_get_grlist @ ./pwutil.c:930 := 0x7f877f45d348
Aug 25 08:29:55 sudo[2392] -> sudo_getgrnam @ ./pwutil.c:719
Aug 25 08:29:55 sudo[2392] -> rbfind @ ./redblack.c:273
Aug 25 08:29:55 sudo[2392] <- rbfind @ ./redblack.c:280 := (nil)
Aug 25 08:29:55 sudo[2392] -> make_gritem @ ./pwutil.c:474
Aug 25 08:29:55 sudo[2392] <- make_gritem @ ./pwutil.c:524 := 0x7f877f44ef20
Aug 25 08:29:55 sudo[2392] -> rbinsert @ ./redblack.c:181
Aug 25 08:29:55 sudo[2392] <- rbinsert @ ./redblack.c:261 := (nil)
Aug 25 08:29:55 sudo[2392] <- sudo_getgrnam @ ./pwutil.c:745 := 0x7f877f44ef38
Aug 25 08:29:55 sudo[2392] -> sudo_grlist_delref @ ./pwutil.c:816
Aug 25 08:29:55 sudo[2392] -> sudo_grlist_delref_item @ ./pwutil.c:805
Aug 25 08:29:55 sudo[2392] <- sudo_grlist_delref_item @ ./pwutil.c:810
Aug 25 08:29:55 sudo[2392] <- sudo_grlist_delref @ ./pwutil.c:818
Aug 25 08:29:55 sudo[2392] <- user_in_group @ ./pwutil.c:1010 := false


I'm quite lost on how to debug further on this.

- On Aug 24, 2016, at 9:50 AM, Jakub Hrozek jhro...@redhat.com wrote:

> On Tue, Aug 23, 2016 at 03:17:48PM +0200, Troels Hansen wrote:
>> Running RHEL 7.2:
>> 
>> ipa-client-4.2.0-15.el7_2.18
>> sssd-ipa-1.13.0-40.el7_2.12.x86_64
>> ipa-server-4.2.0-15.el7_2.18.x86_64
>> 
>> I have a sudo rule where I try to give sudo access based on a AD group.
>> 
>> # groups drext...@net.dr.dk
>> drext...@net.dr.dk : drext...@net.dr.dk ... 
>> domain_us...@linux.dr.dk
>> 
>> I'm member of the group domain_users via AD.
>> 
>> SUDO rule in LDAP:
>> 
>> # guffe, sudoers, linux.dr.dk
>> dn: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk
>> sudoUser: %domain_users
>> sudoRunAsGroup: ALL
>> objectClass: sudoRole
>> objectClass: top
>> sudoCommand: /usr/bin/cat /var/log/messages
>> sudoRunAsUser: ALL
>> sudoHost: ALL
>> cn: guffe
> 
> domain_users != domain_us...@linux.dr.dk
> 
> I'm also curious why sssd qualifies the IPA group name (domain_users is
> an IPA group name right?)
> 
> do you set use_fully_qualified_names=true by chance in the config 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

-- 
Med venlig hilsen 

Troels Hansen 

Systemkonsulent 

Casalogic A/S 


T (+45) 70 20 10 63 

M (+45) 22 43 71 57 

Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og 
meget mere.

-- 
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] Two masters and one of them is desynchronized

[bahan w]

Le 24 août 2016 18:42, "bahan w"  a écrit :

> Hey guys.
>
> I rechecked and in fact I also have the same message on the multi master
> setup with one master unsynchronized :
> ###
> Master: :389 ldap://:389/
> Replica ID: 4
> Replica Root: dc=
> Max CSN: 57bdcd3600010004 (08/24/2016 18:37:10 1 0)
> Receiver: :389 ldap://:389/
> Type: master
> Time Lag: 0:00:00
> Max CSN: 57bdcd3600010004 (08/24/2016 18:37:10 1 0)
> Last Modify Time: 8/24/2016 18:36:32
> Supplier: :389
> Sent/Skipped: 182110 / 1054
> Update Status: 0 Replica acquired successfully: Incremental update
> succeeded
> Update Started: 08/24/2016 18:36:32
> Update Ended: 08/24/2016 18:36:34
> Schedule: always in sync
> SSL: SASL/GSSAPI
>
> Master: :389 ldap://:389/
> Replica ID: 3
> Replica Root: dc=
> Max CSN: 57bdbda10003 (08/24/2016 17:30:41)
> Receiver: :389 ldap://:389/
> Type: master
> Time Lag: - 0:22:29
> Max CSN: 57bdb85c0003 (08/24/2016 17:08:12)
> Last Modify Time: 8/24/2016 17:07:34
> Supplier: :389
> Sent/Skipped: 3 / 9048655
> Update Status: 0 Replica acquired successfully: Incremental update
> succeeded
> Update Started: 08/24/2016 18:36:33
> Update Ended: 08/24/2016 18:36:34
> Schedule: always in sync
> SSL: SASL/GSSAPI
> ###
>
> So even the synchronization looks good no ?
>
> And even with that, this master really is unsynchronized and don't have
> all the users the other master has.
>
> Best regards.
>
> Bahan
>
> On Wed, Aug 24, 2016 at 6:33 PM, bahan w  wrote:
>
>> Hey guys.
>>
>> I performed it :
>> ###
>> # /usr/bin/repl-monitor.pl -f /tmp/checkconf -s
>> Directory Server Replication Status (Version 1.1)
>>
>> Time: Wed Aug 24 2016 18:16:50
>>
>> Master: :389 ldap://:389/
>> Replica ID: 4
>> Replica Root: dc=
>> Max CSN: 57bdc89700030004 (08/24/2016 18:17:27 3 0)
>> Receiver: :389 ldap://:389/
>> Type: master
>> Time Lag: 0:00:00
>> Max CSN: 57bdc89700030004 (08/24/2016 18:17:27 3 0)
>> Last Modify Time: 8/24/2016 18:16:50
>> Supplier: :389
>> Sent/Skipped: 179031 / 1037
>> Update Status: 0 Replica acquired successfully: Incremental update started
>> Update Started: 08/24/2016 18:16:50
>> Update Ended: n/a
>> Schedule: always in sync
>> SSL: SASL/GSSAPI
>>
>> Master: :389 ldap://:389/
>> Replica ID: 3
>> Replica Root: dc=
>> Max CSN: 57bdbda10003 (08/24/2016 17:30:41)
>> Receiver: :389 ldap://:389/
>> Type: master
>> Time Lag: - 0:22:29
>> Max CSN: 57bdb85c0003 (08/24/2016 17:08:12)
>> Last Modify Time: 8/24/2016 17:07:34
>> Supplier: :389
>> Sent/Skipped: 3 / 9045345
>> Update Status: 0 Replica acquired successfully: Incremental update started
>> Update Started: 08/24/2016 18:16:50
>> Update Ended: n/a
>> Schedule: always in sync
>> SSL: SASL/GSSAPI
>> ###
>>
>> Do you see something strange in there ?
>> I have another environment where I have two replicated master and they
>> are OK.
>> And when I check the same command, the result is a little bit different :
>> ###
>> Master: :389 ldap://:389/
>> Replica ID: 4
>> Replica Root: dc=
>> Max CSN: 57bdc88d00030004 (08/24/2016 18:17:17 3 0)
>> Receiver: :389 ldap://:389/
>> Type: master
>> Time Lag: 0:00:00
>> Max CSN: 57bdc88d00030004 (08/24/2016 18:17:17 3 0)
>> Last Modify Time: 8/24/2016 18:16:00
>> Supplier: :389
>> Sent/Skipped: 343515 / 0
>> Update Status: 0 Replica acquired successfully: Incremental update
>> succeeded
>> Update Started: 08/24/2016 18:15:59
>> Update Ended: 08/24/2016 18:16:08
>> Schedule: always in sync
>> SSL: SASL/GSSAPI
>>
>> Master: :389 ldap://:389/
>> Replica ID: 3
>> Replica Root: dc=
>> Max CSN: 57bdc88700080003 (08/24/2016 18:17:11 8 0)
>> Receiver: :389 ldap://:389/
>> Type: master
>> Time Lag: - 390:51:38
>> Max CSN: 57a8500d00040003 (08/08/2016 11:25:33 4 0)
>> Last Modify Time: 8/8/2016 11:24:28
>> Supplier: :389
>> Sent/Skipped: 5 / 2596073
>> Update Status: 0 Replica acquired successfully: Incremental update
>> succeeded
>> Update Started: 08/24/2016 18:16:00
>> Update Ended: 08/24/2016 18:16:12
>> Schedule: always in sync
>> SSL: SASL/GSSAPI
>> ###
>>
>> Best regards.
>>
>> Bahan
>>
>
>
-- 
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] Cleaning Up an Unholy Mess

[Ian Harding]

On 08/24/2016 06:33 PM, Rob Crittenden wrote:
> Ian Harding wrote:
>> I tried to simply uninstall and reinstall freeipa-dal and this happened.
>>
>> It only had a replication agreement with freeipa-sea
>>
>> [root@freeipa-dal ianh]# ipa-server-install --uninstall
>>
>> This is a NON REVERSIBLE operation and will delete all data and
>> configuration!
>>
>> Are you sure you want to continue with the uninstall procedure? [no]: yes
>> Shutting down all IPA services
>> Removing IPA client configuration
>> Unconfiguring ntpd
>> Configuring certmonger to stop tracking system certificates for KRA
>> Configuring certmonger to stop tracking system certificates for CA
>> Unconfiguring CA
>> Unconfiguring named
>> Unconfiguring ipa-dnskeysyncd
>> Unconfiguring web server
>> Unconfiguring krb5kdc
>> Unconfiguring kadmin
>> Unconfiguring directory server
>> Unconfiguring ipa_memcached
>> Unconfiguring ipa-otpd
>> [root@freeipa-dal ianh]# ipa-server-install --uninstall
>>
>> This is a NON REVERSIBLE operation and will delete all data and
>> configuration!
>>
>> Are you sure you want to continue with the uninstall procedure? [no]: yes
>>
>> WARNING: Failed to connect to Directory Server to find information about
>> replication agreements. Uninstallation will continue despite the possible
>> existing replication agreements.
>> Shutting down all IPA services
>> Removing IPA client configuration
>> Configuring certmonger to stop tracking system certificates for KRA
>> Configuring certmonger to stop tracking system certificates for CA
>> [root@freeipa-dal ianh]# ipa-replica-install --setup-ca --setup-dns
>> --no-forwarders /var/lib/ipa/replica-info-freeipa-dal.bpt.rocks.gpg
>> Directory Manager (existing master) password:
>>
>> The host freeipa-dal.bpt.rocks already exists on the master server.
>> You should remove it before proceeding:
>>  % ipa host-del freeipa-dal.bpt.rocks
>> [root@freeipa-dal ianh]#
>>
>> So I tried to delete it again with --force
>>
>> [root@freeipa-sea ianh]# ipa-replica-manage --force del
>> freeipa-dal.bpt.rocks
>> Directory Manager password:
>>
>> 'freeipa-sea.bpt.rocks' has no replication agreement for
>> 'freeipa-dal.bpt.rocks'
>> [root@freeipa-sea ianh]#
>>
>> Can't delete it from the master server either
>>
>> [root@seattlenfs ianh]# ipa host-del freeipa-dal.bpt.rocks
>> ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted or
>> disabled
>>
>>
>> Now what?  I'm running out of things that work.
> 
> Not sure what version of IPA you have but try:
> 
> # ipa-replica-manage --force --cleanup delete freeipa-dal.bpt.rocks
> 
> If this had a CA on it then you'll want to ensure that any replication
> agreements it had have been removed as well.
> 
> rob
> 

It turns out I'm not smart enough to untangle this mess.

Is there any way to kind of start over?  I managed to delete and
recreate a couple replicas but the problems (obsolete ruv as far as I
can tell) carry on with the new replicas.  They won't even replicate
back to the master they were created from.

Basically, is there a way to do a fresh install of FreeIPA server, and
do a dump/restore of data from my existing messed up install?

Thanks!
-- 
Ian Harding
IT Director
Brown Paper Tickets
1-800-838-3006 ext 7186
http://www.brownpapertickets.com

-- 
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] (no subject)

[David Kupka]

On 24/08/16 19:08, Sean Hogan wrote:



Hi All,

  Would anyone be able to direct me to some docs regarding NFS automount
with IPA.  We are currently using this setup but to be specific I do not
want the priv keys to be in the users mounted home.  When I did the keygen
I took the defaults for location and it went into the exported home of the
user meaning it is mounted on any system the user logs onto which is not a
good idea.  Is there a way to set this up so the priv keys stay out of the
mounted home or since I have the keys uploaded into IPA I do not need the
key in home?




Sean Hogan







Hello Sean,

You can find the documentation here:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#automount

But I don't understand what is wrong with the setup. AFAIU NFS, shares 
must be mounted only on machines where you (admin) have full control and 
therefore ownership and access permissions can be enforced. Then ~/.ssh 
directory must have mode 0700 and all files inside it 0600.
If you obey these rules storing ssh keys on NFS share is no less secure 
than storing them locally.


--
David Kupka

--
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] Cleaning Up an Unholy Mess

[Rob Crittenden]

Ian Harding wrote:

I tried to simply uninstall and reinstall freeipa-dal and this happened.

It only had a replication agreement with freeipa-sea

[root@freeipa-dal ianh]# ipa-server-install --uninstall

This is a NON REVERSIBLE operation and will delete all data and
configuration!

Are you sure you want to continue with the uninstall procedure? [no]: yes
Shutting down all IPA services
Removing IPA client configuration
Unconfiguring ntpd
Configuring certmonger to stop tracking system certificates for KRA
Configuring certmonger to stop tracking system certificates for CA
Unconfiguring CA
Unconfiguring named
Unconfiguring ipa-dnskeysyncd
Unconfiguring web server
Unconfiguring krb5kdc
Unconfiguring kadmin
Unconfiguring directory server
Unconfiguring ipa_memcached
Unconfiguring ipa-otpd
[root@freeipa-dal ianh]# ipa-server-install --uninstall

This is a NON REVERSIBLE operation and will delete all data and
configuration!

Are you sure you want to continue with the uninstall procedure? [no]: yes

WARNING: Failed to connect to Directory Server to find information about
replication agreements. Uninstallation will continue despite the possible
existing replication agreements.
Shutting down all IPA services
Removing IPA client configuration
Configuring certmonger to stop tracking system certificates for KRA
Configuring certmonger to stop tracking system certificates for CA
[root@freeipa-dal ianh]# ipa-replica-install --setup-ca --setup-dns
--no-forwarders /var/lib/ipa/replica-info-freeipa-dal.bpt.rocks.gpg
Directory Manager (existing master) password:

The host freeipa-dal.bpt.rocks already exists on the master server.
You should remove it before proceeding:
 % ipa host-del freeipa-dal.bpt.rocks
[root@freeipa-dal ianh]#

So I tried to delete it again with --force

[root@freeipa-sea ianh]# ipa-replica-manage --force del
freeipa-dal.bpt.rocks
Directory Manager password:

'freeipa-sea.bpt.rocks' has no replication agreement for
'freeipa-dal.bpt.rocks'
[root@freeipa-sea ianh]#

Can't delete it from the master server either

[root@seattlenfs ianh]# ipa host-del freeipa-dal.bpt.rocks
ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted or
disabled


Now what?  I'm running out of things that work.


Not sure what version of IPA you have but try:

# ipa-replica-manage --force --cleanup delete freeipa-dal.bpt.rocks

If this had a CA on it then you'll want to ensure that any replication 
agreements it had have been removed as well.


rob

--
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] clean-ruv

[Mark Reynolds]

On 08/24/2016 05:43 PM, Ian Harding wrote:
>
> On 08/24/2016 04:43 AM, Ludwig Krispenz wrote:
>> On 08/24/2016 01:08 AM, Ian Harding wrote:
>>> On 08/23/2016 03:14 AM, Ludwig Krispenz wrote:
 On 08/23/2016 11:52 AM, Ian Harding wrote:
> Ah.  I see.  I mixed those up but I see that those would have to be
> consistent.
>
> However, I have been trying to beat some invalid RUV to death for a
> long
> time and I can't seem to kill them.
>
> For example, bellevuenfs has 9 and 16 which are invalid:
>
> [ianh@seattlenfs ~]$ ldapsearch -ZZ -h seattlenfs.bpt.rocks -D
> "cn=Directory Manager" -W -b "dc=bpt,dc=rocks"
> "(&(objectclass=nstombstone)(nsUniqueId=---))"
>
>
> | grep "nsds50ruv\|nsDS5ReplicaId"
> Enter LDAP Password:
> nsDS5ReplicaId: 7
> nsds50ruv: {replicageneration} 55c8f3640004
> nsds50ruv: {replica 7 ldap://seattlenfs.bpt.rocks:389}
> 568ac3cc0007 57
> nsds50ruv: {replica 20 ldap://freeipa-sea.bpt.rocks:389}
> 57b1037700020014
> nsds50ruv: {replica 18 ldap://bpt-nyc1-nfs.bpt.rocks:389}
> 57a4780100010012
> nsds50ruv: {replica 15 ldap://fremontnis.bpt.rocks:389}
> 57a40386000f 5
> nsds50ruv: {replica 14 ldap://freeipa-dal.bpt.rocks:389}
> 57a2dccd000e
> nsds50ruv: {replica 17 ldap://edinburghnfs.bpt.rocks:389}
> 57a422f90011
> nsds50ruv: {replica 19 ldap://bellevuenfs.bpt.rocks:389}
> 57a4f20d00060013
> nsds50ruv: {replica 16 ldap://bellevuenfs.bpt.rocks:389}
> 57a417060010
> nsds50ruv: {replica 9 ldap://bellevuenfs.bpt.rocks:389}
> 570484ee0009 5
>
>
> So I try to kill them like so:
> [ianh@seattlenfs ~]$ ipa-replica-manage clean-ruv 9 --force --cleanup
> ipa: WARNING: session memcached servers not running
> Clean the Replication Update Vector for bellevuenfs.bpt.rocks:389
>
> Cleaning the wrong replica ID will cause that server to no
> longer replicate so it may miss updates while the process
> is running. It would need to be re-initialized to maintain
> consistency. Be very careful.
> Background task created to clean replication data. This may take a
> while.
> This may be safely interrupted with Ctrl+C
> ^C[ianh@seattlenfs ~]$ ipa-replica-manage clean-ruv 16 --force
> --cleanup
> ipa: WARNING: session memcached servers not running
> Clean the Replication Update Vector for bellevuenfs.bpt.rocks:389
>
> Cleaning the wrong replica ID will cause that server to no
> longer replicate so it may miss updates while the process
> is running. It would need to be re-initialized to maintain
> consistency. Be very careful.
> Background task created to clean replication data. This may take a
> while.
> This may be safely interrupted with Ctrl+C
> ^C[ianh@seattlenfs ~]$ ipa-replica-manage list-clean-ruv
> ipa: WARNING: session memcached servers not running
> CLEANALLRUV tasks
> RID 16: Waiting to process all the updates from the deleted replica...
> RID 9: Waiting to process all the updates from the deleted replica...
>
> No abort CLEANALLRUV tasks running
> [ianh@seattlenfs ~]$ ipa-replica-manage list-clean-ruv
> ipa: WARNING: session memcached servers not running
> CLEANALLRUV tasks
> RID 16: Waiting to process all the updates from the deleted replica...
> RID 9: Waiting to process all the updates from the deleted replica...
>
> and it never finishes.
>
> seattlenfs is the first master, that's the only place I should have to
> run this command, right?
 right, you need to run it only on one master, but this ease of use can
 become the problem.
 The cleanallruv task is propagated to all servers in the topology and it
 does this based on the replication agreements it finds.
 A frequent cause of failure is that replication agreements still exist
 pointing to no longer existing servers. It is a bit tedious, but could
 you run the following search on ALL
 of your current replicas (as directory manager):

 ldapsearch .. -b "cn=config" "objectclass=nsds5replicationagreement"
 nsds5replicahost

 if you find any agreement where nsds5replicahost is a host no longer
 existing or working, delete these agreements.
>>> I have 7 FreeIPA servers, all of which have been in existence in some
>>> form or another since I started.  It used to work great.  I've broken it
>>> now but the hostnames and ip addresses all still exist.  I've
>>> uninstalled and reinstalled them a few times which I think is the source
>>> of my troubles so I tried to straighten out the RUVs and probably messed
>>> that up pretty good
>>>
>>> Anyway, now what I THINK I have is
>>>
>>> seattlenfs
>>> |-freeipa-sea
>>>|- freeipa-dal
>>>|- bellevuenfs
>>>|- fremontnis
>>>|- 

[Freeipa-users] Cleaning Up an Unholy Mess

[Ian Harding]

I tried to simply uninstall and reinstall freeipa-dal and this happened.

It only had a replication agreement with freeipa-sea

[root@freeipa-dal ianh]# ipa-server-install --uninstall

This is a NON REVERSIBLE operation and will delete all data and
configuration!

Are you sure you want to continue with the uninstall procedure? [no]: yes
Shutting down all IPA services
Removing IPA client configuration
Unconfiguring ntpd
Configuring certmonger to stop tracking system certificates for KRA
Configuring certmonger to stop tracking system certificates for CA
Unconfiguring CA
Unconfiguring named
Unconfiguring ipa-dnskeysyncd
Unconfiguring web server
Unconfiguring krb5kdc
Unconfiguring kadmin
Unconfiguring directory server
Unconfiguring ipa_memcached
Unconfiguring ipa-otpd
[root@freeipa-dal ianh]# ipa-server-install --uninstall

This is a NON REVERSIBLE operation and will delete all data and
configuration!

Are you sure you want to continue with the uninstall procedure? [no]: yes

WARNING: Failed to connect to Directory Server to find information about
replication agreements. Uninstallation will continue despite the possible
existing replication agreements.
Shutting down all IPA services
Removing IPA client configuration
Configuring certmonger to stop tracking system certificates for KRA
Configuring certmonger to stop tracking system certificates for CA
[root@freeipa-dal ianh]# ipa-replica-install --setup-ca --setup-dns
--no-forwarders /var/lib/ipa/replica-info-freeipa-dal.bpt.rocks.gpg
Directory Manager (existing master) password:

The host freeipa-dal.bpt.rocks already exists on the master server.
You should remove it before proceeding:
% ipa host-del freeipa-dal.bpt.rocks
[root@freeipa-dal ianh]#

So I tried to delete it again with --force

[root@freeipa-sea ianh]# ipa-replica-manage --force del
freeipa-dal.bpt.rocks
Directory Manager password:

'freeipa-sea.bpt.rocks' has no replication agreement for
'freeipa-dal.bpt.rocks'
[root@freeipa-sea ianh]#

Can't delete it from the master server either

[root@seattlenfs ianh]# ipa host-del freeipa-dal.bpt.rocks
ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted or
disabled


Now what?  I'm running out of things that work.
-- 
Ian Harding
IT Director
Brown Paper Tickets
1-800-838-3006 ext 7186
http://www.brownpapertickets.com

-- 
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] ipa trust-fetch-domains missing

[Chris Moody]

Yes, since we're running it on Centos6 nodes in this case, the repos 
only have IPA 3.0 available...unless you know of a better repo that has 
the 3.3 stuff available ;)


Thank you for the insight.

-Chris

On 8/24/16 2:17 PM, Alexander Bokovoy wrote:

On Wed, 24 Aug 2016, Chris Moody wrote:

Hello.

Wanted to first take a quick moment to thank everyone for their
contributions on making this such a slick packaging and integration of
components.  FreeIPA is a welcome systemthat has been needed for a
LONG time.

I'm running into some trouble in completing my AD-trust setup.

I've followed the guide here:
http://www.freeipa.org/page/Active_Directory_trust_setup

but am not finding the command 'ipa trust-fetch-domains "ad_domain"'.

What concerns me is the statement " With this command running
successfuly, IPA will get information about trusted domains and will
create all needed identity ranges for them." - does this imply that if
this command is NOT run that the creation of the mentioned identity
ranges does not occur?


The following command in the guide (ipa trustdomain-find "ad_domain")
also does not exist, but what appears to be a variant of it (ipa
trust-find) does return these results:

What FreeIPA version do you have? Sounds like FreeIPA 3.0.something.

In FreeIPA 3.0 support for trust to AD was only taking off. Most of
features were added in FreeIPA 3.3 and later, with FreeIPA 4.2 being
most stable.



--
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] clean-ruv

[Ian Harding]

On 08/24/2016 04:43 AM, Ludwig Krispenz wrote:
> 
> On 08/24/2016 01:08 AM, Ian Harding wrote:
>>
>> On 08/23/2016 03:14 AM, Ludwig Krispenz wrote:
>>> On 08/23/2016 11:52 AM, Ian Harding wrote:
 Ah.  I see.  I mixed those up but I see that those would have to be
 consistent.

 However, I have been trying to beat some invalid RUV to death for a
 long
 time and I can't seem to kill them.

 For example, bellevuenfs has 9 and 16 which are invalid:

 [ianh@seattlenfs ~]$ ldapsearch -ZZ -h seattlenfs.bpt.rocks -D
 "cn=Directory Manager" -W -b "dc=bpt,dc=rocks"
 "(&(objectclass=nstombstone)(nsUniqueId=---))"


 | grep "nsds50ruv\|nsDS5ReplicaId"
 Enter LDAP Password:
 nsDS5ReplicaId: 7
 nsds50ruv: {replicageneration} 55c8f3640004
 nsds50ruv: {replica 7 ldap://seattlenfs.bpt.rocks:389}
 568ac3cc0007 57
 nsds50ruv: {replica 20 ldap://freeipa-sea.bpt.rocks:389}
 57b1037700020014
 nsds50ruv: {replica 18 ldap://bpt-nyc1-nfs.bpt.rocks:389}
 57a4780100010012
 nsds50ruv: {replica 15 ldap://fremontnis.bpt.rocks:389}
 57a40386000f 5
 nsds50ruv: {replica 14 ldap://freeipa-dal.bpt.rocks:389}
 57a2dccd000e
 nsds50ruv: {replica 17 ldap://edinburghnfs.bpt.rocks:389}
 57a422f90011
 nsds50ruv: {replica 19 ldap://bellevuenfs.bpt.rocks:389}
 57a4f20d00060013
 nsds50ruv: {replica 16 ldap://bellevuenfs.bpt.rocks:389}
 57a417060010
 nsds50ruv: {replica 9 ldap://bellevuenfs.bpt.rocks:389}
 570484ee0009 5


 So I try to kill them like so:
 [ianh@seattlenfs ~]$ ipa-replica-manage clean-ruv 9 --force --cleanup
 ipa: WARNING: session memcached servers not running
 Clean the Replication Update Vector for bellevuenfs.bpt.rocks:389

 Cleaning the wrong replica ID will cause that server to no
 longer replicate so it may miss updates while the process
 is running. It would need to be re-initialized to maintain
 consistency. Be very careful.
 Background task created to clean replication data. This may take a
 while.
 This may be safely interrupted with Ctrl+C
 ^C[ianh@seattlenfs ~]$ ipa-replica-manage clean-ruv 16 --force
 --cleanup
 ipa: WARNING: session memcached servers not running
 Clean the Replication Update Vector for bellevuenfs.bpt.rocks:389

 Cleaning the wrong replica ID will cause that server to no
 longer replicate so it may miss updates while the process
 is running. It would need to be re-initialized to maintain
 consistency. Be very careful.
 Background task created to clean replication data. This may take a
 while.
 This may be safely interrupted with Ctrl+C
 ^C[ianh@seattlenfs ~]$ ipa-replica-manage list-clean-ruv
 ipa: WARNING: session memcached servers not running
 CLEANALLRUV tasks
 RID 16: Waiting to process all the updates from the deleted replica...
 RID 9: Waiting to process all the updates from the deleted replica...

 No abort CLEANALLRUV tasks running
 [ianh@seattlenfs ~]$ ipa-replica-manage list-clean-ruv
 ipa: WARNING: session memcached servers not running
 CLEANALLRUV tasks
 RID 16: Waiting to process all the updates from the deleted replica...
 RID 9: Waiting to process all the updates from the deleted replica...

 and it never finishes.

 seattlenfs is the first master, that's the only place I should have to
 run this command, right?
>>> right, you need to run it only on one master, but this ease of use can
>>> become the problem.
>>> The cleanallruv task is propagated to all servers in the topology and it
>>> does this based on the replication agreements it finds.
>>> A frequent cause of failure is that replication agreements still exist
>>> pointing to no longer existing servers. It is a bit tedious, but could
>>> you run the following search on ALL
>>> of your current replicas (as directory manager):
>>>
>>> ldapsearch .. -b "cn=config" "objectclass=nsds5replicationagreement"
>>> nsds5replicahost
>>>
>>> if you find any agreement where nsds5replicahost is a host no longer
>>> existing or working, delete these agreements.
>> I have 7 FreeIPA servers, all of which have been in existence in some
>> form or another since I started.  It used to work great.  I've broken it
>> now but the hostnames and ip addresses all still exist.  I've
>> uninstalled and reinstalled them a few times which I think is the source
>> of my troubles so I tried to straighten out the RUVs and probably messed
>> that up pretty good
>>
>> Anyway, now what I THINK I have is
>>
>> seattlenfs
>> |-freeipa-sea
>>|- freeipa-dal
>>|- bellevuenfs
>>|- fremontnis
>>|- bpt-nyc1-nfs
>>|- edinburghnfs
>>
>> Until I get this squared away I've turned off ipa services on all but
>> seattlenfs, freeipa-sea and freeipa-da

Re: [Freeipa-users] ipa trust-fetch-domains missing

[Alexander Bokovoy]

On Wed, 24 Aug 2016, Chris Moody wrote:

Hello.

Wanted to first take a quick moment to thank everyone for their 
contributions on making this such a slick packaging and integration of 
components.  FreeIPA is a welcome systemthat has been needed for a 
LONG time.


I'm running into some trouble in completing my AD-trust setup.

I've followed the guide here: 
http://www.freeipa.org/page/Active_Directory_trust_setup


but am not finding the command 'ipa trust-fetch-domains "ad_domain"'.

What concerns me is the statement " With this command running 
successfuly, IPA will get information about trusted domains and will 
create all needed identity ranges for them." - does this imply that if 
this command is NOT run that the creation of the mentioned identity 
ranges does not occur?



The following command in the guide (ipa trustdomain-find "ad_domain") 
also does not exist, but what appears to be a variant of it (ipa 
trust-find) does return these results:

What FreeIPA version do you have? Sounds like FreeIPA 3.0.something.

In FreeIPA 3.0 support for trust to AD was only taking off. Most of
features were added in FreeIPA 3.3 and later, with FreeIPA 4.2 being
most stable.

--
/ Alexander Bokovoy

--
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] KDC returned error string: NOT_ALLOWED_TO_DELEGATE

[Linov Suresh]

IPA Server 1 do not have HTTP as well as ldap principal. Just wondering how
do we add HTTP and ldap principal to the delegation list using ldapmodify.

I'm new to IPA, your help is appreciated.

On Wed, Aug 24, 2016 at 4:32 PM, Rob Crittenden  wrote:

> Linov Suresh wrote:
>
>> Look like our issue is discussed here, and *is **missing one or more
>> memberPrincipal*.
>>
>> https://www.redhat.com/archives/freeipa-users/2013-April/msg00228.html
>>
>> When I tried to add the Principal, I'm getting error,
>>
>
> You didn't follow the instructions in the e-mail thread. The problem isn't
> a principal that doesn't exist, it is a principal not in the delegation
> list. Do the ldapsearch's and see what is missing (and you'll need to use
> -Y GSSAPI instead of -x) then add it using ldapmodify.
>
> Only under very specific circumstances would I ever recommend using
> kadmin.local.
>
> rob
>
>
>>
>> [root@ipa01 ~]# kadmin.local
>> Authenticating as principal admin/ad...@teloip.net
>>  with password.
>> kadmin.local:  addprinc -randkey HTTP/ipa02.teloip@teloip.net
>> 
>> WARNING: no policy specified for HTTP/ipa02.teloip@teloip.net
>> ; defaulting to no policy
>> add_principal: Principal or policy already exists while creating
>> "HTTP/ipa02.teloip@teloip.net "
>>
>> [root@ipa01 ~]# kadmin.local
>> Authenticating as principal admin/ad...@teloip.net
>>  with password.
>> kadmin.local:  addprinc -randkey ldap/ipa02.teloip@teloip.net
>> 
>> WARNING: no policy specified for ldap/ipa02.teloip@teloip.net
>> ; defaulting to no policy
>> add_principal: Principal or policy already exists while creating
>> "ldap/ipa02.teloip@teloip.net ".
>>
>> Could you please help us to fix the "*KDC returned error string:
>> NOT_ALLOWED_TO_DELEGATE*" error?
>>
>>
>> [root@caer ~]# kadmin.local
>> Authenticating as principal admin/ad...@teloip.net
>>  with password.
>> kadmin.local:  addprinc -randkey HTTP/neit.teloip@teloip.net
>> 
>> WARNING: no policy specified for HTTP/neit.teloip@teloip.net
>> ; defaulting to no policy
>> add_principal: Principal or policy already exists while creating
>> "HTTP/neit.teloip@teloip.net "
>>
>>
>>
>>
>>
>>
>> On Tue, Aug 16, 2016 at 7:58 AM, Martin Kosek > > wrote:
>>
>> On 08/16/2016 09:25 AM, Petr Spacek wrote:
>> > On 15.8.2016 20:18, Linov Suresh wrote:
>> >> We have IPA replica set up in RHEL 6.4 and is FreeIPA 3.0.0
>> >>
>> >>
>> >> We can only add the clients from IPA Server 01, not from IPA
>> Server 02.
>> >> When I tried to add the client from IPA Server 02, getting the
>> error,
>> >>
>> >>
>> >> ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI
>> Error:
>> >> Unspecified GSS failure.  Minor code may provide more information
>> (KDC
>> >> returned error string: NOT_ALLOWED_TO_DELEGATE)
>> >>
>> >> SASL/GSSAPI authentication started
>> >>
>> >> SASL username:vp...@example.net 
>> >>
>> >> SASL SSF: 56
>> >>
>> >> SASL data security layer installed.
>> >>
>> >> ldap_modify: No such object (32)
>> >>
>> >> additional info: Range Check error
>> >>
>> >> modifying entry "fqdn=cpe-5061747522f9.example.net <
>> http://cpe-5061747522f9.example.net>
>> >> ,cn=computers,cn=accounts,dc=example,dc=net"
>> >>
>> >>
>> >> Could you please help us to fix this?
>> >
>>  > We need to see exact steps you did before we can give you any
>> meaningful advice.
>>  >
>>  > Please have a look at
>>  > http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
>> 
>>  >
>>  > It is a very nice document which describes general bug reporting
>> procedure and
>>  > best practices.
>>  >
>>  > We will certainly have a look but we need first see the
>> information :-)
>>  >
>>
>> Also, using IPA on RHEL-6.4 is discouraged. This is a really old
>> release and
>> there are known issues (in cert renewals for example). Using at
>> least RHEL-6.8
>> or, even better, RHEL-7.2 is preferred and would help you avoid
>> known issues
>> and deficiencies (and the newer FreeIPA versions are way cooler
>> anyway).
>>
>>
>>
>>
>>
>
-- 
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] ipa trust-fetch-domains missing

[Chris Moody]

Hello.

Wanted to first take a quick moment to thank everyone for their 
contributions on making this such a slick packaging and integration of 
components.  FreeIPA is a welcome systemthat has been needed for a LONG 
time.


I'm running into some trouble in completing my AD-trust setup.

I've followed the guide here: 
http://www.freeipa.org/page/Active_Directory_trust_setup


but am not finding the command 'ipa trust-fetch-domains "ad_domain"'.

What concerns me is the statement " With this command running 
successfuly, IPA will get information about trusted domains and will 
create all needed identity ranges for them." - does this imply that if 
this command is NOT run that the creation of the mentioned identity 
ranges does not occur?



The following command in the guide (ipa trustdomain-find "ad_domain") 
also does not exist, but what appears to be a variant of it (ipa 
trust-find) does return these results:

=
[root@ca1-infra-ipa1 ~]# ipa trust-find
---
1 trust matched
---
  Realm name: ad.X.com
  Domain NetBIOS name: AD
  Domain Security Identifier: S-1-5-21-754923713-4108838501-2041013861
  Trust type: Active Directory domain

Number of entries returned 1

=
[root@ca1-infra-ipa1 ~]# ipa trust-show "ad.X.com"
  Realm name: ad.X.com
  Domain NetBIOS name: AD
  Domain Security Identifier: S-1-5-21-754923713-4108838501-2041013861
  Trust direction: Two-way trust
  Trust type: Active Directory domain
[root@ca1-infra-ipa1 ~]#
=

I'm just wanting to confirm whether or not the 'trust-fetch-domains' 
command that's listed in the guide is essential to complete the AD trust 
setup or if it's simply providing an informational output.


Thanks,
-Chris
-- 
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] KDC returned error string: NOT_ALLOWED_TO_DELEGATE

[Rob Crittenden]

Linov Suresh wrote:

Look like our issue is discussed here, and *is **missing one or more
memberPrincipal*.

https://www.redhat.com/archives/freeipa-users/2013-April/msg00228.html

When I tried to add the Principal, I'm getting error,


You didn't follow the instructions in the e-mail thread. The problem 
isn't a principal that doesn't exist, it is a principal not in the 
delegation list. Do the ldapsearch's and see what is missing (and you'll 
need to use -Y GSSAPI instead of -x) then add it using ldapmodify.


Only under very specific circumstances would I ever recommend using 
kadmin.local.


rob




[root@ipa01 ~]# kadmin.local
Authenticating as principal admin/ad...@teloip.net
 with password.
kadmin.local:  addprinc -randkey HTTP/ipa02.teloip@teloip.net

WARNING: no policy specified for HTTP/ipa02.teloip@teloip.net
; defaulting to no policy
add_principal: Principal or policy already exists while creating
"HTTP/ipa02.teloip@teloip.net "

[root@ipa01 ~]# kadmin.local
Authenticating as principal admin/ad...@teloip.net
 with password.
kadmin.local:  addprinc -randkey ldap/ipa02.teloip@teloip.net

WARNING: no policy specified for ldap/ipa02.teloip@teloip.net
; defaulting to no policy
add_principal: Principal or policy already exists while creating
"ldap/ipa02.teloip@teloip.net ".

Could you please help us to fix the "*KDC returned error string:
NOT_ALLOWED_TO_DELEGATE*" error?


[root@caer ~]# kadmin.local
Authenticating as principal admin/ad...@teloip.net
 with password.
kadmin.local:  addprinc -randkey HTTP/neit.teloip@teloip.net

WARNING: no policy specified for HTTP/neit.teloip@teloip.net
; defaulting to no policy
add_principal: Principal or policy already exists while creating
"HTTP/neit.teloip@teloip.net "






On Tue, Aug 16, 2016 at 7:58 AM, Martin Kosek mailto:mko...@redhat.com>> wrote:

On 08/16/2016 09:25 AM, Petr Spacek wrote:
> On 15.8.2016 20:18, Linov Suresh wrote:
>> We have IPA replica set up in RHEL 6.4 and is FreeIPA 3.0.0
>>
>>
>> We can only add the clients from IPA Server 01, not from IPA Server 02.
>> When I tried to add the client from IPA Server 02, getting the error,
>>
>>
>> ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI Error:
>> Unspecified GSS failure.  Minor code may provide more information (KDC
>> returned error string: NOT_ALLOWED_TO_DELEGATE)
>>
>> SASL/GSSAPI authentication started
>>
>> SASL username:vp...@example.net 
>>
>> SASL SSF: 56
>>
>> SASL data security layer installed.
>>
>> ldap_modify: No such object (32)
>>
>> additional info: Range Check error
>>
>> modifying entry "fqdn=cpe-5061747522f9.example.net 

>> ,cn=computers,cn=accounts,dc=example,dc=net"
>>
>>
>> Could you please help us to fix this?
>
 > We need to see exact steps you did before we can give you any
meaningful advice.
 >
 > Please have a look at
 > http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

 >
 > It is a very nice document which describes general bug reporting
procedure and
 > best practices.
 >
 > We will certainly have a look but we need first see the
information :-)
 >

Also, using IPA on RHEL-6.4 is discouraged. This is a really old
release and
there are known issues (in cert renewals for example). Using at
least RHEL-6.8
or, even better, RHEL-7.2 is preferred and would help you avoid
known issues
and deficiencies (and the newer FreeIPA versions are way cooler anyway).






--
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] KDC returned error string: NOT_ALLOWED_TO_DELEGATE

[Linov Suresh]

Look like our issue is discussed here, and *is **missing one or more
memberPrincipal*.

https://www.redhat.com/archives/freeipa-users/2013-April/msg00228.html

When I tried to add the Principal, I'm getting error,


[root@ipa01 ~]# kadmin.local
Authenticating as principal admin/ad...@teloip.net with password.
kadmin.local:  addprinc -randkey HTTP/ipa02.teloip@teloip.net
WARNING: no policy specified for HTTP/ipa02.teloip@teloip.net;
defaulting to no policy
add_principal: Principal or policy already exists while creating "HTTP/
ipa02.teloip@teloip.net"

[root@ipa01 ~]# kadmin.local
Authenticating as principal admin/ad...@teloip.net with password.
kadmin.local:  addprinc -randkey ldap/ipa02.teloip@teloip.net
WARNING: no policy specified for ldap/ipa02.teloip@teloip.net;
defaulting to no policy
add_principal: Principal or policy already exists while creating "ldap/
ipa02.teloip@teloip.net".

Could you please help us to fix the "*KDC returned error string:
NOT_ALLOWED_TO_DELEGATE*" error?


[root@caer ~]# kadmin.local
Authenticating as principal admin/ad...@teloip.net with password.
kadmin.local:  addprinc -randkey HTTP/neit.teloip@teloip.net
WARNING: no policy specified for HTTP/neit.teloip@teloip.net;
defaulting to no policy
add_principal: Principal or policy already exists while creating "HTTP/
neit.teloip@teloip.net"








On Tue, Aug 16, 2016 at 7:58 AM, Martin Kosek  wrote:

> On 08/16/2016 09:25 AM, Petr Spacek wrote:
> > On 15.8.2016 20:18, Linov Suresh wrote:
> >> We have IPA replica set up in RHEL 6.4 and is FreeIPA 3.0.0
> >>
> >>
> >> We can only add the clients from IPA Server 01, not from IPA Server 02.
> >> When I tried to add the client from IPA Server 02, getting the error,
> >>
> >>
> >> ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI
> Error:
> >> Unspecified GSS failure.  Minor code may provide more information (KDC
> >> returned error string: NOT_ALLOWED_TO_DELEGATE)
> >>
> >> SASL/GSSAPI authentication started
> >>
> >> SASL username: vp...@example.net
> >>
> >> SASL SSF: 56
> >>
> >> SASL data security layer installed.
> >>
> >> ldap_modify: No such object (32)
> >>
> >> additional info: Range Check error
> >>
> >> modifying entry "fqdn=cpe-5061747522f9.example.net
> >> ,cn=computers,cn=accounts,dc=example,dc=net"
> >>
> >>
> >> Could you please help us to fix this?
> >
> > We need to see exact steps you did before we can give you any meaningful
> advice.
> >
> > Please have a look at
> > http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
> >
> > It is a very nice document which describes general bug reporting
> procedure and
> > best practices.
> >
> > We will certainly have a look but we need first see the information :-)
> >
>
> Also, using IPA on RHEL-6.4 is discouraged. This is a really old release
> and
> there are known issues (in cert renewals for example). Using at least
> RHEL-6.8
> or, even better, RHEL-7.2 is preferred and would help you avoid known
> issues
> and deficiencies (and the newer FreeIPA versions are way cooler anyway).
>
-- 
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] Default gid for AD trust users

[Orion Poplawski]

While that is definitely *a* convention, it's not the one we've used which
puts users by default in shared groups (nwra, visitors, etc).  For example:

uid=2941(user) gid=1991(nwra)

We may be fine changing conventions, but I'm researching whether or not we
have to.

Thanks.

On 08/24/2016 11:19 AM, Justin Stephenson wrote:
> Could you please explain further what you are trying to accomplish with an AD
> trust default group? I believe we are following the standard linux convention
> of creating a user private group using the ID number which matches the uid
> number for AD trust users.
> 
> Kind regards,
> 
> Justin Stephenson
> 
> 
> On 08/23/2016 06:27 PM, Orion Poplawski wrote:
>> Is there any way to control the default gid for AD trust users?  At the 
>> moment
>> each user has it's own default group, e.g.:
>>
>> uid=22603(user@ad.domain) gid=22603(user@ad.domain)
>>
>> It would be nice to be able to set this to an actual group.
>>
>> Thanks.
>>
> 


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com

-- 
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] Default gid for AD trust users

[Justin Stephenson]

Could you please explain further what you are trying to accomplish with 
an AD trust default group? I believe we are following the standard linux 
convention of creating a user private group using the ID number which 
matches the uid number for AD trust users.


Kind regards,

Justin Stephenson


On 08/23/2016 06:27 PM, Orion Poplawski wrote:

Is there any way to control the default gid for AD trust users?  At the moment
each user has it's own default group, e.g.:

uid=22603(user@ad.domain) gid=22603(user@ad.domain)

It would be nice to be able to set this to an actual group.

Thanks.



--
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] (no subject)

[Sean Hogan]

Hi All,

  Would anyone be able to direct me to some docs regarding NFS automount
with IPA.  We are currently using this setup but to be specific I do not
want the priv keys to be in the users mounted home.  When I did the keygen
I took the defaults for location and it went into the exported home of the
user meaning it is mounted on any system the user logs onto which is not a
good idea.  Is there a way to set this up so the priv keys stay out of the
mounted home or since I have the keys uploaded into IPA I do not need the
key in home?




Sean Hogan


-- 
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] Two masters and one of them is desynchronized

[bahan w]

Hey guys.

I performed it :
###
# /usr/bin/repl-monitor.pl -f /tmp/checkconf -s
Directory Server Replication Status (Version 1.1)

Time: Wed Aug 24 2016 18:16:50

Master: :389 ldap://:389/
Replica ID: 4
Replica Root: dc=
Max CSN: 57bdc89700030004 (08/24/2016 18:17:27 3 0)
Receiver: :389 ldap://:389/
Type: master
Time Lag: 0:00:00
Max CSN: 57bdc89700030004 (08/24/2016 18:17:27 3 0)
Last Modify Time: 8/24/2016 18:16:50
Supplier: :389
Sent/Skipped: 179031 / 1037
Update Status: 0 Replica acquired successfully: Incremental update started
Update Started: 08/24/2016 18:16:50
Update Ended: n/a
Schedule: always in sync
SSL: SASL/GSSAPI

Master: :389 ldap://:389/
Replica ID: 3
Replica Root: dc=
Max CSN: 57bdbda10003 (08/24/2016 17:30:41)
Receiver: :389 ldap://:389/
Type: master
Time Lag: - 0:22:29
Max CSN: 57bdb85c0003 (08/24/2016 17:08:12)
Last Modify Time: 8/24/2016 17:07:34
Supplier: :389
Sent/Skipped: 3 / 9045345
Update Status: 0 Replica acquired successfully: Incremental update started
Update Started: 08/24/2016 18:16:50
Update Ended: n/a
Schedule: always in sync
SSL: SASL/GSSAPI
###

Do you see something strange in there ?
I have another environment where I have two replicated master and they are
OK.
And when I check the same command, the result is a little bit different :
###
Master: :389 ldap://:389/
Replica ID: 4
Replica Root: dc=
Max CSN: 57bdc88d00030004 (08/24/2016 18:17:17 3 0)
Receiver: :389 ldap://:389/
Type: master
Time Lag: 0:00:00
Max CSN: 57bdc88d00030004 (08/24/2016 18:17:17 3 0)
Last Modify Time: 8/24/2016 18:16:00
Supplier: :389
Sent/Skipped: 343515 / 0
Update Status: 0 Replica acquired successfully: Incremental update succeeded
Update Started: 08/24/2016 18:15:59
Update Ended: 08/24/2016 18:16:08
Schedule: always in sync
SSL: SASL/GSSAPI

Master: :389 ldap://:389/
Replica ID: 3
Replica Root: dc=
Max CSN: 57bdc88700080003 (08/24/2016 18:17:11 8 0)
Receiver: :389 ldap://:389/
Type: master
Time Lag: - 390:51:38
Max CSN: 57a8500d00040003 (08/08/2016 11:25:33 4 0)
Last Modify Time: 8/8/2016 11:24:28
Supplier: :389
Sent/Skipped: 5 / 2596073
Update Status: 0 Replica acquired successfully: Incremental update succeeded
Update Started: 08/24/2016 18:16:00
Update Ended: 08/24/2016 18:16:12
Schedule: always in sync
SSL: SASL/GSSAPI
###

Best regards.

Bahan
-- 
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] clean-ruv

[Mark Reynolds]

On 08/23/2016 05:52 AM, Ian Harding wrote:
> Ah.  I see.  I mixed those up but I see that those would have to be
> consistent.
>
> However, I have been trying to beat some invalid RUV to death for a long
> time and I can't seem to kill them.
>
> For example, bellevuenfs has 9 and 16 which are invalid:
>
> [ianh@seattlenfs ~]$ ldapsearch -ZZ -h seattlenfs.bpt.rocks -D
> "cn=Directory Manager" -W -b "dc=bpt,dc=rocks"
> "(&(objectclass=nstombstone)(nsUniqueId=---))"
> | grep "nsds50ruv\|nsDS5ReplicaId"
> Enter LDAP Password:
> nsDS5ReplicaId: 7
> nsds50ruv: {replicageneration} 55c8f3640004
> nsds50ruv: {replica 7 ldap://seattlenfs.bpt.rocks:389}
> 568ac3cc0007 57
> nsds50ruv: {replica 20 ldap://freeipa-sea.bpt.rocks:389}
> 57b1037700020014
> nsds50ruv: {replica 18 ldap://bpt-nyc1-nfs.bpt.rocks:389}
> 57a4780100010012
> nsds50ruv: {replica 15 ldap://fremontnis.bpt.rocks:389}
> 57a40386000f 5
> nsds50ruv: {replica 14 ldap://freeipa-dal.bpt.rocks:389}
> 57a2dccd000e
> nsds50ruv: {replica 17 ldap://edinburghnfs.bpt.rocks:389}
> 57a422f90011
> nsds50ruv: {replica 19 ldap://bellevuenfs.bpt.rocks:389}
> 57a4f20d00060013
> nsds50ruv: {replica 16 ldap://bellevuenfs.bpt.rocks:389}
> 57a417060010
> nsds50ruv: {replica 9 ldap://bellevuenfs.bpt.rocks:389}
> 570484ee0009 5
>
>
> So I try to kill them like so:
> [ianh@seattlenfs ~]$ ipa-replica-manage clean-ruv 9 --force --cleanup
> ipa: WARNING: session memcached servers not running
> Clean the Replication Update Vector for bellevuenfs.bpt.rocks:389
>
> Cleaning the wrong replica ID will cause that server to no
> longer replicate so it may miss updates while the process
> is running. It would need to be re-initialized to maintain
> consistency. Be very careful.
> Background task created to clean replication data. This may take a while.
> This may be safely interrupted with Ctrl+C
> ^C[ianh@seattlenfs ~]$ ipa-replica-manage clean-ruv 16 --force --cleanup
> ipa: WARNING: session memcached servers not running
> Clean the Replication Update Vector for bellevuenfs.bpt.rocks:389
>
> Cleaning the wrong replica ID will cause that server to no
> longer replicate so it may miss updates while the process
> is running. It would need to be re-initialized to maintain
> consistency. Be very careful.
> Background task created to clean replication data. This may take a while.
> This may be safely interrupted with Ctrl+C
> ^C[ianh@seattlenfs ~]$ ipa-replica-manage list-clean-ruv
> ipa: WARNING: session memcached servers not running
> CLEANALLRUV tasks
> RID 16: Waiting to process all the updates from the deleted replica...
> RID 9: Waiting to process all the updates from the deleted replica...
Looks like you are hitting a bug that is fixed in newer versions of
389-ds-base.  The current version of 389-ds-base/cleanAllRUV does not
wait for updates from the deleted replica if you use the force option. 
Since you did use the force option, and it's still waiting, that tells
me you are hitting this old bug and ultimately you need to upgrade or
get a hotfix(if you are paying customer). 

I do not know what version of 389 you are on, or if it's possible to
upgrade, but with your current version the cleanAllRUV task is not going
to be able to finish.

You can always "abort" the current "clean"  tasks that are not working
(look for the abort section from the link below), but unfortunately you
won't be able to clean those rids until you upgrade 389-ds-base.

http://www.port389.org/docs/389ds/howto/howto-cleanruv.html#cleanallruv

Regards,
Mark
>
> No abort CLEANALLRUV tasks running
> [ianh@seattlenfs ~]$ ipa-replica-manage list-clean-ruv
> ipa: WARNING: session memcached servers not running
> CLEANALLRUV tasks
> RID 16: Waiting to process all the updates from the deleted replica...
> RID 9: Waiting to process all the updates from the deleted replica...
>
> and it never finishes.
>
> seattlenfs is the first master, that's the only place I should have to
> run this command, right?
>
> I'm about to burn everything down and ipa-server-install --uninstall but
> I've done that before a couple times and that seems to be what got me
> into this mess...
>
> Thank you for your help.
>
>
>
>
> On 08/23/2016 01:37 AM, Ludwig Krispenz wrote:
>> looks like you are searching the nstombstone below "o=ipaca", but you
>> are cleaning ruvs in "dc=bpt,dc=rocks",
>>
>> your attrlist_replace error refers to the bpt,rocks backend, so you
>> should search the tombstone entry ther, then determine which replicaIDs
>> to remove.
>>
>> Ludwig
>>
>> On 08/23/2016 09:20 AM, Ian Harding wrote:
>>> I've followed the procedure in this thread:
>>>
>>> https://www.redhat.com/archives/freeipa-users/2016-May/msg00043.html
>>>
>>> and found my list of RUV that don't have an existing replica id.
>>>
>>> I've tried to remove them like so:
>>>
>>> [root@seattlenfs ianh]# ldapmodify -D "cn=directory manager" -W -a
>>> Enter LDAP Password:
>>>

Re: [Freeipa-users] clean-ruv

[Ludwig Krispenz]

On 08/24/2016 01:08 AM, Ian Harding wrote:


On 08/23/2016 03:14 AM, Ludwig Krispenz wrote:

On 08/23/2016 11:52 AM, Ian Harding wrote:

Ah.  I see.  I mixed those up but I see that those would have to be
consistent.

However, I have been trying to beat some invalid RUV to death for a long
time and I can't seem to kill them.

For example, bellevuenfs has 9 and 16 which are invalid:

[ianh@seattlenfs ~]$ ldapsearch -ZZ -h seattlenfs.bpt.rocks -D
"cn=Directory Manager" -W -b "dc=bpt,dc=rocks"
"(&(objectclass=nstombstone)(nsUniqueId=---))"

| grep "nsds50ruv\|nsDS5ReplicaId"
Enter LDAP Password:
nsDS5ReplicaId: 7
nsds50ruv: {replicageneration} 55c8f3640004
nsds50ruv: {replica 7 ldap://seattlenfs.bpt.rocks:389}
568ac3cc0007 57
nsds50ruv: {replica 20 ldap://freeipa-sea.bpt.rocks:389}
57b1037700020014
nsds50ruv: {replica 18 ldap://bpt-nyc1-nfs.bpt.rocks:389}
57a4780100010012
nsds50ruv: {replica 15 ldap://fremontnis.bpt.rocks:389}
57a40386000f 5
nsds50ruv: {replica 14 ldap://freeipa-dal.bpt.rocks:389}
57a2dccd000e
nsds50ruv: {replica 17 ldap://edinburghnfs.bpt.rocks:389}
57a422f90011
nsds50ruv: {replica 19 ldap://bellevuenfs.bpt.rocks:389}
57a4f20d00060013
nsds50ruv: {replica 16 ldap://bellevuenfs.bpt.rocks:389}
57a417060010
nsds50ruv: {replica 9 ldap://bellevuenfs.bpt.rocks:389}
570484ee0009 5


So I try to kill them like so:
[ianh@seattlenfs ~]$ ipa-replica-manage clean-ruv 9 --force --cleanup
ipa: WARNING: session memcached servers not running
Clean the Replication Update Vector for bellevuenfs.bpt.rocks:389

Cleaning the wrong replica ID will cause that server to no
longer replicate so it may miss updates while the process
is running. It would need to be re-initialized to maintain
consistency. Be very careful.
Background task created to clean replication data. This may take a while.
This may be safely interrupted with Ctrl+C
^C[ianh@seattlenfs ~]$ ipa-replica-manage clean-ruv 16 --force --cleanup
ipa: WARNING: session memcached servers not running
Clean the Replication Update Vector for bellevuenfs.bpt.rocks:389

Cleaning the wrong replica ID will cause that server to no
longer replicate so it may miss updates while the process
is running. It would need to be re-initialized to maintain
consistency. Be very careful.
Background task created to clean replication data. This may take a while.
This may be safely interrupted with Ctrl+C
^C[ianh@seattlenfs ~]$ ipa-replica-manage list-clean-ruv
ipa: WARNING: session memcached servers not running
CLEANALLRUV tasks
RID 16: Waiting to process all the updates from the deleted replica...
RID 9: Waiting to process all the updates from the deleted replica...

No abort CLEANALLRUV tasks running
[ianh@seattlenfs ~]$ ipa-replica-manage list-clean-ruv
ipa: WARNING: session memcached servers not running
CLEANALLRUV tasks
RID 16: Waiting to process all the updates from the deleted replica...
RID 9: Waiting to process all the updates from the deleted replica...

and it never finishes.

seattlenfs is the first master, that's the only place I should have to
run this command, right?

right, you need to run it only on one master, but this ease of use can
become the problem.
The cleanallruv task is propagated to all servers in the topology and it
does this based on the replication agreements it finds.
A frequent cause of failure is that replication agreements still exist
pointing to no longer existing servers. It is a bit tedious, but could
you run the following search on ALL
of your current replicas (as directory manager):

ldapsearch .. -b "cn=config" "objectclass=nsds5replicationagreement"
nsds5replicahost

if you find any agreement where nsds5replicahost is a host no longer
existing or working, delete these agreements.

I have 7 FreeIPA servers, all of which have been in existence in some
form or another since I started.  It used to work great.  I've broken it
now but the hostnames and ip addresses all still exist.  I've
uninstalled and reinstalled them a few times which I think is the source
of my troubles so I tried to straighten out the RUVs and probably messed
that up pretty good

Anyway, now what I THINK I have is

seattlenfs
|-freeipa-sea
   |- freeipa-dal
   |- bellevuenfs
   |- fremontnis
   |- bpt-nyc1-nfs
   |- edinburghnfs

Until I get this squared away I've turned off ipa services on all but
seattlenfs, freeipa-sea and freeipa-dal and am hoping that any password
changes etc. happen on seattlenfs.  I need the other two because they
are my DNS.  The rest I can kind of live without since they are just
local instances living on nfs servers.

Here's the output from that ldap query on all the hosts:

yes, looks like the replication agreements are fine, but the RUVs are not.

In the o=ipaca suffix, there is a reference to bellvuenis:

 [{replica 76
ldap://bellevuenis.bpt.rocks:389} 56f385eb0007004c


but this seems to be now bellevuenfs.

In the dc=bpt,dc=rocks replica 

Re: [Freeipa-users] can't get sudo to work.

[Lukas Slebodnik]

On (24/08/16 06:55), Tony Brian Albers wrote:
>And indeed the compat tree was disabled.
>
>Guess I forgot to reenable it after copying the db to a testing
>environment.
>
>Thanks guys, sudo is working fine now.
>
BTW it would work with upstream 1.13.4 even with disabled
compat tree (or 1.13.3 in el6)

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] Two masters and one of them is desynchronized

[Petr Spacek]

Hi,

again, please always keep freeipa-users@redhat.com in Cc of your e-mails. This
is not a private support channel.

Ludwig, do you know if dataversion is expected to be consistent among all
replicas or not? I would not expect consistent values.

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Configuration_Command_and_File_Reference/rootdse-attributes.html#dataversion

did not answer this question. If we find out the right answer we should extend
the description in documentation.

Petr^2 Spacek

On 24.8.2016 12:12, bahan w wrote:
> Re.
> 
> I checked the conflicts but I didn't find any between the two servers.
> ###
> 
> ldapsearch -x -D "cn=directory manager" -W -b "dc="
> "nsds5ReplConflict=*" \* nsds5ReplConflict
> ###
> 
> The only thing I see is that one my master is in IPA 3.0.0.42 and another
> is IPA 3.0.0.47.
> The server with a problem of synchronization is 3.0.0.47.
> 
> Here is a partial result from the command on each server:
> ###
> ldapsearch -Y GSSAPI -h `hostname` -b "" -s base
> ###
> 
> On the server OK
> ###
> 
> vendorVersion: 389-Directory/1.2.11.15 B2015.247.1737
> dataversion: 020160823201940
> 
> ###
> 
> 
> On the server with the problem of sync :
> 
> ###
> 
> vendorVersion: 389-Directory/1.2.11.15 B2015.022.1831
> dataversion: 020160823195011
> ###
> 
> Is the field dataversion the timestamp of the last version of the ldap
> database ?
> 
> I'm going to increase loglevel to DEBUG this afternoon before anything.
> 
> I found this in the red hat doc :
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/ipa-replica-manage.html
> 
> ###
> 28.5.4. Reinitializing IdM Servers
> When a replica is first created, the database of the master server is
> copied, completely, over to the replica database. This process is called
> *initialization*. If a server/replica is offline for a long period of time
> or there is some kind of corruption in its database, then the server can be
> re-initialized, with a fresh and updated set of data.
> This is done using the re-initialize command. The target server being
> initialized is the local host. The server or replica from which to pull the
> data to initialize the local database is specified in the --from option:
> 
> [root@server ~]# ipa-replica-manage re-initialize --from srv1.example.com
> 
> ###
> 
> Do you know if it is available in IPA 3.0.0.47 ?
> 
> Best regards.
> 
> Bahan
> 
> On Wed, Aug 24, 2016 at 11:50 AM, bahan w  wrote:
> 
>> Hello Petr, Orion.
>>
>> I checked the errors log from the dirsrv on both masters and I found
>> nothing related to an error with the replication plugin.
>>
>> I also performed all the tests described in the link Petr provided. Thank
>> you for this. Every one of this command is OK on both masters.
>>
>> I'm checking the access logs from dirsrv now.
>>
>> Any other tracks to follow ? Increase the log level on the replica failing
>> to sync ?
>>
>> Best regards.
>>
>> Bahan
>>
>> On Wed, Aug 24, 2016 at 8:41 AM, Petr Spacek  wrote:
>>
>>> On 23.8.2016 22:44, bahan w wrote:
 Hello !

 I am using IPA 3.0.0 on RedHat 6.6 servers.

 I have two masters and this evening, I realized that one of them was
 desynchronized, some users and groups were missing.

 I was wondering if there was an ipa command to resynchronize replica
>>> which
 are not sync with the other ?
>>>
>>> First of all, it is necessary to find out replication does not work.
>>>
>>> Please see
>>> http://www.freeipa.org/page/Troubleshooting#Replication_issues
>>>
>>> --
>>> Petr^2 Spacek

-- 
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] Two masters and one of them is desynchronized

[Petr Spacek]

Hi,

please keep freeipa-users@redhat.com in Cc.

If there are no problems indicated in log, is it really a problem with
replication or something else?

I would try

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Monitoring_Replication_Status.html#replication-monitoring-script

and see if replication is working or not.

Petr^2 Spacek

On 24.8.2016 11:50, bahan w wrote:
> Hello Petr, Orion.
> 
> I checked the errors log from the dirsrv on both masters and I found
> nothing related to an error with the replication plugin.
> 
> I also performed all the tests described in the link Petr provided. Thank
> you for this. Every one of this command is OK on both masters.
> 
> I'm checking the access logs from dirsrv now.
> 
> Any other tracks to follow ? Increase the log level on the replica failing
> to sync ?
> 
> Best regards.
> 
> Bahan
> 
> On Wed, Aug 24, 2016 at 8:41 AM, Petr Spacek  wrote:
> 
>> On 23.8.2016 22:44, bahan w wrote:
>>> Hello !
>>>
>>> I am using IPA 3.0.0 on RedHat 6.6 servers.
>>>
>>> I have two masters and this evening, I realized that one of them was
>>> desynchronized, some users and groups were missing.
>>>
>>> I was wondering if there was an ipa command to resynchronize replica
>> which
>>> are not sync with the other ?
>>
>> First of all, it is necessary to find out replication does not work.
>>
>> Please see
>> http://www.freeipa.org/page/Troubleshooting#Replication_issues
>>
>> --
>> Petr^2 Spacek

-- 
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] SUDO and group lookup in AD trust

[Jakub Hrozek]

On Tue, Aug 23, 2016 at 03:17:48PM +0200, Troels Hansen wrote:
> Running RHEL 7.2: 
> 
> ipa-client-4.2.0-15.el7_2.18 
> sssd-ipa-1.13.0-40.el7_2.12.x86_64 
> ipa-server-4.2.0-15.el7_2.18.x86_64 
> 
> I have a sudo rule where I try to give sudo access based on a AD group. 
> 
> # groups drext...@net.dr.dk 
> drext...@net.dr.dk : drext...@net.dr.dk ... 
> domain_us...@linux.dr.dk 
> 
> I'm member of the group domain_users via AD. 
> 
> SUDO rule in LDAP: 
> 
> # guffe, sudoers, linux.dr.dk 
> dn: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk 
> sudoUser: %domain_users 
> sudoRunAsGroup: ALL 
> objectClass: sudoRole 
> objectClass: top 
> sudoCommand: /usr/bin/cat /var/log/messages 
> sudoRunAsUser: ALL 
> sudoHost: ALL 
> cn: guffe 

domain_users != domain_us...@linux.dr.dk

I'm also curious why sssd qualifies the IPA group name (domain_users is
an IPA group name right?)

do you set use_fully_qualified_names=true by chance in the config 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] Freeipa 4.2.0 hangs intermittently

[Petr Spacek]

On 23.8.2016 18:44, Rakesh Rajasekharan wrote:
> I think thers something seriously wrong with my system
> 
> not able to run any  IPA commands
> 
> klist
> Ticket cache: KEYRING:persistent:0:0
> Default principal: ad...@xyz.com
> 
> Valid starting   Expires  Service principal
> 2016-08-23T16:26:36  2016-08-24T16:26:22  krbtgt/xyz@xyz.com
> 
> 
> [root@prod-ipa-master-1a :~] ipactl status
> Directory Service: RUNNING
> krb5kdc Service: RUNNING
> kadmin Service: RUNNING
> ipa_memcached Service: RUNNING
> httpd Service: RUNNING
> pki-tomcatd Service: RUNNING
> ipa-otpd Service: RUNNING
> ipa: INFO: The ipactl command was successful
> 
> 
> 
> [root@prod-ipa-master :~] ipa user-find p-testuser
> ipa: ERROR: Kerberos error: ('Unspecified GSS failure.  Minor code may
> provide more information', 851968)/("Cannot contact any KDC for realm '
> XYZ.COM'", -1765328228)
> 

This is weird because the server seems to be up.

Please follow
http://www.freeipa.org/page/Troubleshooting#Authentication.2FKerberos

Petr^2 Spacek

> 
> 
> Thanks
> 
> Rakesh
> 
> On Tue, Aug 23, 2016 at 10:01 PM, Rakesh Rajasekharan <
> rakesh.rajasekha...@gmail.com> wrote:
> 
>> i changed the loggin level to 4 . Modifying nsslapd-accesslog-level
>>
>> But, the hang is still there. though I dont see the sigfault now
>>
>>
>>
>>
>> On Tue, Aug 23, 2016 at 9:02 PM, Rakesh Rajasekharan <
>> rakesh.rajasekha...@gmail.com> wrote:
>>
>>> My disk was getting filled too fast
>>>
>>> logs under /var/log/dirsrv was coming around 5 gb quickly filling up
>>>
>>> Is there a way to make the logging less verbose
>>>
>>>
>>>
>>> On Tue, Aug 23, 2016 at 6:41 PM, Petr Spacek  wrote:
>>>
 On 23.8.2016 15:07, Rakesh Rajasekharan wrote:
> I was able to fix that may be temporarily... when i checked the
 network..
> there was another process that was running and consuming a lot of
 network (
> i have no idea who did that. I need to seriously start restricting
 people
> access to this machine )
>
> after killing that perfomance improved drastically
>
> But now, suddenly I started experiencing the same hang.
>
> This time , I gert the following error when checked dmesg
>
> [  301.236976] ns-slapd[3124]: segfault at 0 ip 7f1de416951c sp
> 7f1dee1dba70 error 4 in libcos-plugin.so[7f1de4166000+b000]
> [ 1116.248431] TCP: request_sock_TCP: Possible SYN flooding on port 88.
> Sending cookies.  Check SNMP counters.
> [11831.397037] ns-slapd[22550]: segfault at 0 ip 7f533d82251c sp
> 7f5347894a70 error 4 in libcos-plugin.so[7f533d81f000+b000]
> [11832.727989] ns-slapd[22606]: segfault at 0 ip 7f6231eb951c sp
> 7f623bf2ba70 error 4 in libcos-plugin.so[7f6231eb6000+b00

 Okay, this one is serious. The LDAP server crashed.

 1. Make sure all your packages are up-to-date.

 Please see
 http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#d
 ebugging-crashes
 for further instructions how to debug this.

 Petr^2 Spacek

>
> and in /var/log/dirsrv/example-com/errors
>
> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
 could
> not delete change record 3291138 (rc: 32)
> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
 could
> not delete change record 3291139 (rc: 32)
> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
 could
> not delete change record 3291140 (rc: 32)
> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
 could
> not delete change record 3291141 (rc: 32)
> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
 could
> not delete change record 3291142 (rc: 32)
> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
 could
> not delete change record 3291143 (rc: 32)
> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
 could
> not delete change record 3291144 (rc: 32)
> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
 could
> not delete change record 3291145 (rc: 32)
> [23/Aug/2016:12:49:50 +] - Retry count exceeded in delete
> [23/Aug/2016:12:49:50 +] DSRetroclPlugin - delete_changerecord:
 could
> not delete change record 3292734 (rc: 51)
>
>
> Can  i do something about this error.. I treid to restart ipa a couple
 of
> time but that did not help
>
> Thanks
> Rakesh
>
> On Mon, Aug 22, 2016 at 2:27 PM, Petr Spacek 
 wrote:
>
>> On 19.8.2016 19:32, Rakesh Rajasekharan wrote:
>>> I am running my set up on AWS cloud, and entropy is low at around
 180 .
>>>
>>> I plan to increase it bu installing haveged . But, would low entropy
 by
>> any
>>> chance cause this issue of intermittent hang .
>>> Also, the hang is mostly observed when regi

Re: [Freeipa-users] Freeipa-users Digest, Vol 97, Issue 97

[siology.io]

>
>
> Date: Tue, 23 Aug 2016 10:20:32 -0400
> From: Rob Crittenden 
> To: "siology.io" ,freeipa-users
> 
> Subject: Re: [Freeipa-users] private user groups for existing users
> Message-ID: <57bc5bb0.7090...@redhat.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> siology.io wrote:
> >   i've noticed that some of my users (imported from openldap) don't have
> > personal user groups, but the new ones that i make within freeipa do.
> >
> > Is there a way of marking the existing accounts such that they get user
> > groups made for them ? I couldn't seem to see the groups that IPA is
> > making in the LDAP output so it must be creating them via some other
> means.
> >
> > Is there some sort of  'ipa user create-private-group ' command ?
> >
> > The only work around i have is to make hundreds of fake private groups
> > by making normal user groups each with one user, which'll clutter the UI
> > up with pointless groups.
>
> Yeah, there is a ticket open to allow UPG creation in migration but as
> you see, it isn't done yet.
>
> There is no documented way to do it but it should be possible with
> ldapmodify. I forget the exact ordering but I'd probably do the group
> first, then the user. In theory you can convert a group to be managed by
> adding:
>
> objectclass: mepmanagedentry
> mepmanagedby: uid=,cn=users,cn=accounts,$SUFFIX
>
> And removing:
>
> objectclass: groupofnames
> objectclass: nestedgroup
>
> You also need to update the user with:
>
> objectclass: meporiginentry
> mepmanagedentry: cn=,cn=groups,cn=accounts,$SUFFIX
>
> Just don't do this with any groups that have members.
>
> Definitely worth experimenting on a non-production installation.
>
> rob
>


I'm not too hot with ldapmodify at all. So far i've got:
http://pastebin.com/MDE1SN0F but i dont think that's working for me.
-- 
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] can't get sudo to work.

[Tony Brian Albers]

And indeed the compat tree was disabled.

Guess I forgot to reenable it after copying the db to a testing
environment.

Thanks guys, sudo is working fine now.

/tony

On Tue, 2016-08-23 at 10:13 -0400, Rob Crittenden wrote:
> Pavel Březina wrote:
> > On 08/23/2016 01:55 PM, Tony Brian Albers wrote:
> >> Here you are:
> >>
> >>
> >> [root ~]# ldapsearch -Y GSSAPI -b $dc
> >> '(ou=*)' -s onelevel
> >
> >> # profile, $domain
> >> dn: ou=profile,$dc
> >> objectClass: top
> >> objectClass: organizationalUnit
> >> ou: profiles
> >> ou: profile
> >>
> >> # search result
> >> search: 4
> >> result: 0 Success
> >>
> >> # numResponses: 2
> >> # numEntries: 1
> >
> >
> > Sudo rules are not downloaded by SSSD because ou=sudoers is missing on
> > the IPA server, or it may have incorrect ACL. Does someone from IPA team
> > know why?
> 
> Perhaps the compat tree is disabled:
> 
> $ ipa-compat-manage status
> 
> rob
> 
> 

-- 
Best regards,

Tony Albers
Systems administrator, IT-development
State and University Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark.
Tel: +45 8946 2316




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