AD - IPA Trust Issues
by Matt Wells
Hello everyone. I hoped I could ask for a little assistance on an AD / IPA
Trust.
I've for a Windows 2008R2 domain.
Response Type: LOGON_SAM_LOGON_RESPONSE_EX
GUID: e**********************6497
Flags:
Is a PDC: no
Is a GC of the forest: yes
Is an LDAP server: yes
Supports DS: yes
Is running a KDC: yes
Is running time services: yes
Is the closest DC: yes
Is writable: yes
Has a hardware clock: no
Is a non-domain NC serviced by LDAP server: no
Is NT6 DC that has some secrets: no
Is NT6 DC that has all secrets: yes
Runs Active Directory Web Services: yes
Runs on Windows 2012 or later: no
Forest: example.local
Domain: example.local
Domain Controller: CSAD1.example.local
Pre-Win2k Domain: example
Pre-Win2k Hostname: CSAD1
Server Site Name : Site1
Client Site Name : Site1
NT Version: 5
LMNT Token: ffff
LM20 Token: ffff
-----------------
IPA
ipa-server-4.4.0-14.el7
Domain = lci.example.com
------------------
I start the process and DNS lookups are working.
[root@ipa-001 samba]# !872
dig SRV _ldap._tcp.example.local
; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.3 <<>> SRV _ldap._tcp.example.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45828
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_ldap._tcp.example.local. IN SRV
;; ANSWER SECTION:
_ldap._tcp.example.local. 600 IN SRV 0 100 389 ac-ad4.example.local.
_ldap._tcp.example.local. 600 IN SRV 0 100 389 csad2.example.local.
_ldap._tcp.example.local. 600 IN SRV 0 100 389 csad1.example.local.
_ldap._tcp.example.local. 600 IN SRV 0 100 389 ac-ad3.example.local.
;; ADDITIONAL SECTION:
csad1.example.local. 3196 IN A 192.168.2.1
ac-ad4.example.local. 3196 IN A 192.168.2.4
ac-ad3.example.local. 3196 IN A 192.168.2.3
csad2.example.local. 3196 IN A 192.168.2.2
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jun 09 19:50:34 UTC 2017
;; MSG SIZE rcvd: 290
[root@ipa-001 samba]# dig SRV _ldap._tcp.lci.example.local
; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.3 <<>> SRV
_ldap._tcp.lci.example.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64288
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_ldap._tcp.lci.example.local. IN SRV
;; ANSWER SECTION:
_ldap._tcp.lci.example.local. 86400 IN CNAME _ldap._tcp.atl._locations.lci.
example.local.
_ldap._tcp.atl._locations.lci.example.local. 86400 IN SRV 0 5 389
ipa-001.lci.example.local.
_ldap._tcp.atl._locations.lci.example.local. 86400 IN SRV 0 10 389
ipa-002.lci.example.local.
;; AUTHORITY SECTION:
lci.example.local. 86400 IN NS ipa-002.lci.example.local.
lci.example.local. 86400 IN NS ipa-001.lci.example.local.
;; ADDITIONAL SECTION:
ipa-001.lci.example.local. 1200 IN A 192.168.1.11
ipa-002.lci.example.local. 1200 IN A 192.168.1.12
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jun 09 19:50:40 UTC 2017
;; MSG SIZE rcvd: 272
[root@ipa-001 samba]#
--------------
My bound `ldapsearch` and `kinit` on both domains domain work well.
As I move onto testing the `trust-fetch-domains` area things go bad ( well
start to show they are ).
--------------
[root@ipa-001 samba]# ipa trust-fetch-domains example.local
------------------------------------------------------------
----------------------------
List of trust domains successfully refreshed. Use trustdomain-find command
to list them.
------------------------------------------------------------
----------------------------
----------------------------
Number of entries returned 0
----------------------------
[root@ipa-001 samba]# ipa trustdomain-find example.LOCAL
Domain name: example.local
Domain NetBIOS name: example
Domain Security Identifier: S-1-5-21-******-857828577-140568808
Domain enabled: True
----------------------------
Number of entries returned 1
----------------------------
Of course any movement from there on fails.
Using other posts I bumped up the logging and pulled out items that I
believe assist in this matter.
----------
log.winbindd-dc-connect: check_negative_conn_cache returning result 0 for
domain example.local server 192.168.2.3
log.winbindd-dc-connect: check_negative_conn_cache returning result
-1073741823 for domain example.local server 192.168.2.2
log.winbindd-dc-connect: check_negative_conn_cache returning result
-1073741823 for domain example.local server 192.168.2.4
log.winbindd-dc-connect: get_sorted_dc_list: attempting lookup for name
example.local (sitename NULL)
log.winbindd-dc-connect: saf_fetch: failed to find server for
"example.local" domain
log.winbindd-dc-connect: internal_resolve_name: looking up
example.local#1c (sitename (null))
log.winbindd-dc-connect: name example.local#1C found.
log.winbindd-dc-connect: check_negative_conn_cache returning result
-1073741823 for domain example.local server 192.168.2.1
log.winbindd-dc-connect: Adding cache entry with
key=[NEG_CONN_CACHE/example.local,192.168.2.3] and timeout=[Thu Jan 1
12:00:00 AM 1970 UTC] (-1497038264 seconds in the past)
log.winbindd-dc-connect: check_negative_conn_cache returning result 0 for
domain example.local server 192.168.2.3
log.winbindd-dc-connect: check_negative_conn_cache returning result
-1073741823 for domain example.local server 192.168.2.2
log.winbindd-dc-connect: check_negative_conn_cache returning result
-1073741823 for domain example.local server 192.168.2.4
log.winbindd-dc-connect: get_sorted_dc_list: attempting lookup for name
example.local (sitename NULL)
log.winbindd-dc-connect: saf_fetch: failed to find server for
"example.local" domain
log.winbindd-dc-connect: internal_resolve_name: looking up
example.local#1c (sitename (null))
log.winbindd-dc-connect: name example.local#1C found.
log.winbindd-dc-connect: check_negative_conn_cache returning result
-1073741823 for domain example.local server 192.168.2.1
log.winbindd-dc-connect: Adding cache entry with
key=[NEG_CONN_CACHE/example.local,192.168.2.3] and timeout=[Thu Jan 1
12:00:00 AM 1970 UTC] (-1497038340 seconds in the past)
log.winbindd-dc-connect: check_negative_conn_cache returning result 0 for
domain example.local server 192.168.2.3
log.winbindd-dc-connect: check_negative_conn_cache returning result
-1073741823 for domain example.local server 192.168.2.2
log.winbindd-dc-connect: check_negative_conn_cache returning result
-1073741823 for domain example.local server 192.168.2.4
log.winbindd-idmap: pdb_init_ipasam: support for pdb_enum_upn_suffixes
enabled for domain lci.example.local
-------------------
I see in the logs the timeouts however I thought they appeared to conflict
with the ability to `net ads lookup`.
Any assistance on this would be appreciated a great deal. Thank you so
much for your time and looking at this.
6 years, 3 months
Enroll CentOS 5 on FreeIPA 4.3
by Jose Alvarez R.
Hello
A question
What another way I can enroll my server client on my IPA server ?
I have a server IPA with S.O. Fedora 24 and
freeipa-server-4.3.3-1.fc24.x86_64
My client server have a S.O. CentOS release 5.10 with
ipa-client-2.1.3-7.el5
This is the "ipa-client-install -d"
[root@l1 ~]# ipa-client-install -d
root : DEBUG /usr/sbin/ipa-client-install was invoked with
options: {'conf_ntp': True, 'domain': None, 'uninstall': False, 'force':
False, 'sssd': True, 'krb5_offline_passwords': True, 'hostname': None,
'permit': False, 'server': None, 'prompt_password': False, 'mkhomedir':
False, 'dns_updates': False, 'preserve_sssd': False, 'debug': True,
'on_master': False, 'ca_cert_file': None, 'realm_name': None, 'unattended':
None, 'ntp_server': None, 'principal': None}
root : DEBUG missing options might be asked for interactively
later
root : DEBUG Loading Index file from
'/var/lib/ipa-client/sysrestore/sysrestore.index'
root : DEBUG Loading StateFile from
'/var/lib/ipa-client/sysrestore/sysrestore.state'
root : DEBUG [IPA Discovery]
root : DEBUG Starting IPA discovery with domain=None,
servers=None, hostname=l1.example.com
root : DEBUG [ipadnssearchldap(example.com)]
root : DEBUG [ipadnssearchkrb]
root : DEBUG [ipacheckldap]
root : DEBUG Verifying that ipa.example.com (realm EXAMPLE.COM) is
an IPA server
root : DEBUG Init ldap with: ldap://ipa.example.com:389
root : DEBUG Search LDAP server for IPA base DN
root : DEBUG Check if naming context 'cn=changelog' is for IPA
root : DEBUG Info attribute with IPA server version not found
root : DEBUG Check if naming context 'dc=example,dc=com' is for
IPA
root : DEBUG Naming context 'dc=example,dc=com' is a valid IPA
context
root : DEBUG Search for (objectClass=krbRealmContainer) in
dc=example,dc=com(sub)
root : DEBUG Found:
[('cn=example.COM,cn=kerberos,dc=example,dc=com', {'objectClass': ['top',
'krbrealmcontainer', 'krbticketpolicyaux'], 'cn': ['example.COM']})]
root : DEBUG Discovery result: Success; server=ipa.example.com,
domain=example.com, kdc=ipa.example.com, basedn=dc=example,dc=com
root : DEBUG Validated servers: ipa.example.com
root : DEBUG will use domain: example.com
root : DEBUG [ipadnssearchldap(example.com)]
root : DEBUG DNS validated, enabling discovery
root : DEBUG will use discovered server: ipa.example.com
Discovery was successful!
root : DEBUG will use cli_realm: EXAMPLE.COM
root : DEBUG will use cli_basedn: dc=example,dc=com
Hostname: l1.example.com
Realm: example.COM
DNS Domain: example.com
IPA Server: ipa.example.com
BaseDN: dc=example,dc=com
Continue to configure the system with these values? [no]: yes
User authorized to enroll computers: admin
root : DEBUG will use principal: admin
Synchronizing time with KDC...
root : DEBUG args=/usr/sbin/ntpdate -U ntp -s -b ipa.example.com
root : DEBUG stdout=
root : DEBUG stderr=
root : DEBUG Writing Kerberos configuration to /tmp/tmpSeQjKB:
#File modified by ipa-client-install
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
example.COM = {
kdc = ipa.example.com:88
master_kdc = ipa.example.com:88
admin_server = ipa.example.com:749
default_domain = example.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
Password for admin(a)EXAMPLE.COM:
root : DEBUG args=kinit admin(a)EXAMPLE.COM
root : DEBUG stdout=Password for admin(a)EXAMPLE.COM:
root : DEBUG stderr=
root : DEBUG trying to retrieve CA cert via LDAP from
ldap://ipa.example.com
root : DEBUG Existing CA cert and Retrieved CA cert are identical
In the line "root : DEBUG Existing CA cert and Retrieved CA cert
are identical" It's don't progress.
Do Is there any other way I could do it ?
Thanks for your response
Jose Alvarez
6 years, 3 months
very slow remove users process
by Adrian HY
Hi folks, I have a freeipa group with 30000 users to delete. The process is
very very slow. For example:
# time ipa -v user-del vvv
-------------------------
Deleted user "vvv"
-------------------------
real 0m16.913s
user 0m0.814s
sys 0m0.084s
The hardware parameters are normal. The hard drive is SSD.
Regards.
6 years, 3 months
ipa-client package - is it necessary after install?
by Lachlan Musicman
Hola,
So in doing a system analysis, I noted that some of our hosts have
ipa-client and some don't.
All of the hosts are using SSSD to connect to the FreeIPA server.
Once a client system has joined the domain successfully and users can
login, is ipa-client still necessary?
(ie, the real question is: in order to get uniformity, do I install
ipa-client on all hosts or remove ipa-client from all hosts)
cheers
L.
------
"Mission Statement: To provide hope and inspiration for collective action,
to build collective power, to achieve collective transformation, rooted in
grief and rage but pointed towards vision and dreams."
- Patrisse Cullors, *Black Lives Matter founder*
6 years, 3 months
Replication error
by Bret Wortman
I've also just realized that replication appears to have ceased; I have
entries in some IPA servers but not all.
[root@zsipa ~]# ipa-replica-manage list
Directory Manager password:
zsipa.damascusgrp.com: master
zsipa2.damascusgrp.com: master
zsipa3.damascusgrp.com: master
[root@zsipa ~]# ipa-replica-manage list zsipa.damascusgrp.com
Directory Manager password:
zsipa3.damascusgrp.com: replica
last init status: None
last init ended: 1970-01-01 00:00:00+00:00
last update status: Error (19) Replication error acquiring replica:
Replica has different database generation ID, remote replica may need to
be initialized (RUV error)
last update ended: 1970-01-01 00:00:00+00:00
[root@zsipa ~]#
Only zsipa3 is listed as a replica anywhere, and it's not a functioning
one. I can set up replication between zsipa and zsipa2, but is there a
good way to bring zsipa3 back in line as well?
The background is that we attempted to do a rolling update of our IPA
servers by bringing in a new server, zsipa2, and then upgrading each of
the other two from Fedora to Centos 7 and then initialized them as
replicas of zsipa2. But apparently, this didn't work as we had thought.
So add replication errors to the certificate issue I'm still trying to
run to ground.
--
*Bret Wortman*
Damascus Products
ph/fax: 1-855-644-2783
Wrap Buddies <wrapbuddies.co/store> now available for preorder!
6 years, 3 months
Re: FreeIPA-users Digest, Vol 2, Issue 2
by Chris Scutcher
unsubscribe
On 3 June 2017 at 05:04, <freeipa-users-request(a)lists.fedorahosted.org>
wrote:
> Send FreeIPA-users mailing list submissions to
> freeipa-users(a)lists.fedorahosted.org
>
> To subscribe or unsubscribe via email, send a message with subject or
> body 'help' to
> freeipa-users-request(a)lists.fedorahosted.org
>
> You can reach the person managing the list at
> freeipa-users-owner(a)lists.fedorahosted.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of FreeIPA-users digest..."
>
> Today's Topics:
>
> 1. Re: ipa-adtrust-install command fails to add fallback group
> (Sumit Bose)
> 2. Re: Time Skew on Amazon nodes? (Ludwig Krispenz)
> 3. status of auditd integration on freeipa clients (Sven Kieske)
> 4. Re: IPA and CM? (Simo Sorce)
> 5. new/fresh server can't be setup as replica due to "The remote
> replica has a different database generation ID ..."
> (Chris Dagdigian)
> 6. Re: DatabaseError: Server is unwilling to perform: Too many failed
> logins.
> (Jose Alvarez R.)
> 7. Re: IPA and CM? (Kat)
> 8. Re: IPA and CM? (Simo Sorce)
> 9. Re: IPA and CM? (Alexander Bokovoy)
> 10. FreeIPA for simply managing DNS (Striker Leggette)
> 11. FreeIPA (adding all new users to admin group by default?)
> (Devin Acosta)
> 12. Re: FreeIPA (adding all new users to admin group by default?)
> (Rob Crittenden)
> 13. Re: FreeIPA (adding all new users to admin group by default?)
> (Devin Acosta)
> 14. Re: FreeIPA (adding all new users to admin group by default?)
> (wouter.hummelink(a)kpn.com)
> 15. Re: FreeIPA (adding all new users to admin group by default?)
> (Devin Acosta)
> 16. export users to new freeipa server (Adrian HY)
> 17. Re: export users to new freeipa server (Striker Leggette)
> 18. Scripting a SSSD client to add SID to UIDnumbers from ad
> Trust into custom LDAP schema. (Frank Rey)
> 19. Re: FreeIPA for simply managing DNS (Brendan Kearney)
>
>
> ----------------------------------------------------------------------
>
> Date: Fri, 2 Jun 2017 09:49:34 +0200
> From: Sumit Bose <sbose(a)redhat.com>
> Subject: [Freeipa-users] Re: ipa-adtrust-install command fails to add
> fallback group
> To: freeipa-users(a)lists.fedorahosted.org
> Message-ID:
> <20170602074934.GJ29267(a)p.Speedport_W_724V_Typ_A_05011603_00_011>
> Content-Type: text/plain; charset=utf-8
>
> On Thu, Jun 01, 2017 at 04:41:52PM +0000, Marin BERNARD via FreeIPA-users
> wrote:
> > Hi,
> >
> > I'm trying to configure ad trust on a freshly installed FreeIPA server
> 4.4.0 running on an up-to-date instance of CentOS 7 (1611). The
> ipa-adtrust-install command fails at step 17 (failed to add fallback
> group). As a consequence, Samba cannot be started and AD trusts can't be
> established.
> >
> > Here is an excerpt of the install log:
> >
> > ````
> > # ipa-adtrust-install --netbios-name=PEP06-IPA --add-sids --enable-compat
> >
> > (...)
> >
> > 2017-06-01T13:49:29Z DEBUG [18/23]: adding fallback group
> > 2017-06-01T13:49:29Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd-IPA-PEP06-FR.socket
> from SchemaCache
> > 2017-06-01T13:49:29Z DEBUG retrieving schema for SchemaCache
> url=ldapi://%2fvar%2frun%2fslapd-IPA-PEP06-FR.socket
> conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x62107a0>
> > 2017-06-01T13:49:30Z DEBUG Starting external process
> > 2017-06-01T13:49:30Z DEBUG args=/usr/bin/ldapmodify -v -f /tmp/tmpyj5xIJ
> -H ldapi://%2fvar%2frun%2fslapd-IPA-PEP06-FR.socket -Y EXTERNAL
> > 2017-06-01T13:49:30Z DEBUG Process finished, return code=1
> > 2017-06-01T13:49:30Z DEBUG stdout=add cn:
> > Default SMB Group
> > add description:
> > Fallback group for primary group RID, do not add users to this
> group
> > add gidnumber:
> > -1
> > add objectclass:
> > top
> > ipaobject
> > posixgroup
> > adding new entry "cn=Default SMB Group,cn=groups,cn=accounts,
> dc=ipa,dc=pep06,dc=fr"
> >
> >
> > 2017-06-01T13:49:30Z DEBUG stderr=ldap_initialize(
> ldapi://%2Fvar%2Frun%2Fslapd-IPA-PEP06-FR.socket/??base )
> > SASL/EXTERNAL authentication started
> > SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> > SASL SSF: 0
> > ldap_add: Operations error (1)
> > additional info: Allocation of a new value for range cn=posix
> ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed!
> Unable to proceed.
>
> The DNA plugin (used to generate new UIDs and GIDs) has some issues.
> Maybe https://blog-rcritten.rhcloud.com/?p=50 can help?
>
> If the DNA plugin works again you can run ipa-adtrust-install which then
> should properly generate the fallback group.
>
> HTH
>
> bye,
> Sumit
>
> >
> > 2017-06-01T13:49:30Z CRITICAL Failed to load default-smb-group.ldif:
> Command '/usr/bin/ldapmodify -v -f /tmp/tmpyj5xIJ -H
> ldapi://%2fvar%2frun%2fslapd-IPA-PEP06-FR.socket -Y EXTERNAL' returned
> non-zero exit status 1
> > 2017-06-01T13:49:30Z DEBUG Failed to add fallback group.
> > 2017-06-01T13:49:30Z DEBUG duration: 0 seconds
> >
> > (...)
> >
> > ````
> >
> > In the end, Samba logically fails to start with the following error:
> >
> > ````
> > Missing mandatory attribute ipaNTFallbackPrimaryGroup.
> >
> > ````
> >
> > I ran the same command one week ago on another server and had no issue.
> > Does anybody have an idea about what to do to make it work ?
> >
> > Thanks,
> >
> > Marin BERNARD
> > Administrateur systèmes
> > Pupilles de l’Enseignement Public 06
> > 35 boulevard de la Madeleine — 06300 Nice
> > marin.bernard[at]pep06.fr
>
> > _______________________________________________
> > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> > To unsubscribe send an email to freeipa-users-leave@lists.
> fedorahosted.org
>
> ------------------------------
>
> Date: Fri, 02 Jun 2017 10:09:12 +0200
> From: Ludwig Krispenz <lkrispen(a)redhat.com>
> Subject: [Freeipa-users] Re: Time Skew on Amazon nodes?
> To: freeipa-users(a)lists.fedorahosted.org
> Message-ID: <59311D28.2060008(a)redhat.com>
> Content-Type: multipart/alternative;
> boundary="------------090802020609060703090300"
>
> This is a multi-part message in MIME format.
> --------------090802020609060703090300
> Content-Type: text/plain; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: 7bit
>
> replication uses CSNs(change sequence numbers) to synchronize data
> across the topology, and it requires the times to be in sync and that
> time never goes backward, otherwise a new change would get an older csn
> and probably be ignored after repliciation.
> Since it is not guaranteed that system time is always is sync and that
> no one plays with the time setting, replcation uses its own csn state,
> maintainig the local system time and remote or local offsets when
> differnces in time were detected. This ensures that time is in sync, as
> good as possible, and that time never goes backward.
> Unfortunately these offsets can accumulate over time and reach a value
> where replication "thinks" it is insane to continue and raises the clock
> skew error.
> In my opinion this should not be a fatal error, but right now it is,
> feel free to log an RFE.
>
> Now, the csns are part of all the individual data in the servers's
> database, so you cannot just clean them up, also if you add a new
> replica it will inherit the offsets present in other servers.
> Unfortunately I only see the hard way to get out of this: export the
> data without state information(csns), reimport and reinitialize. That's
> in the doc you referenced
>
> Ludwig
>
> On 06/01/2017 09:29 PM, pgb205 via FreeIPA-users wrote:
> > I have noticed that we had a broken replication agreement between
> > replica in amazon and on another physical node.
> > I have attempted to re-initialize but received
> > /Update failed! Status: [2 Replication error acquiring replica:
> > excessive clock skew]/
> >
> >
> > I had triple verified that time on both is correct and at most within
> > seconds of each other.
> >
> > in dirsrv logs I get
> > /Excessive clock skew from supplier RUV/
> > /Unable to acquire replica: error: excessive clock skew/
> > /
> > /
> > After doing a bit of searching I found this beauty:
> > https://www.redhat.com/archives/freeipa-users/2014-
> February/msg00007.html
> >
> > The article mentions that the time skew might occur due to server
> > being virtualied, and I'm wondering if this is applicable to Amazon.
> >
> > The steps mentioned in the article look intrusive (and intimidating) .
> > I'm curious what other avenues are available to me to fix this?
> > If I blow away the replica and re-set up the new one from scratch
> > would that fix the problem.
> >
> >
> >
> > _______________________________________________
> > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> > To unsubscribe send an email to freeipa-users-leave@lists.
> fedorahosted.org
>
> --
> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill,
> Eric Shander
>
>
> --------------090802020609060703090300
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
> <html>
> <head>
> <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Ty=
> pe">
> </head>
> <body bgcolor=3D"#FFFFFF" text=3D"#000000">
> replication uses CSNs(change sequence numbers) to synchronize data
> across the topology, and it requires the times to be in sync and
> that time never goes backward, otherwise a new change would get an
> older csn and probably be ignored after repliciation.<br>
> Since it is not guaranteed that system time is always is sync and
> that no one plays with the time setting, replcation uses its own csn
> state, maintainig the local system time and remote or local offsets
> when differnces in time were detected. This ensures that time is in
> sync, as good as possible, and that time never goes backward.<br>
> Unfortunately these offsets can accumulate over time and reach a
> value where replication "thinks" it is insane to continue and raises
> the clock skew error.<br>
> In my opinion this should not be a fatal error, but right now it is,
> feel free to log an RFE.<br>
> <br>
> Now, the csns are part of all the individual data in the servers's
> database, so you cannot just clean them up, also if you add a new
> replica it will inherit the offsets present in other servers.
> Unfortunately I only see the hard way to get out of this: export the
> data without state information(csns), reimport and reinitialize.
> That's in the doc you referenced<br>
> <br>
> Ludwig<br>
> <br>
> <div class=3D"moz-cite-prefix">On 06/01/2017 09:29 PM, pgb205 via
> FreeIPA-users wrote:<br>
> </div>
> <blockquote
> cite=3D"mid:1514317342.632956.1496345396127@mail.yahoo.com"
> type=3D"cite">
> <meta http-equiv=3D"Context-Type" content=3D"text/html; charset=3DU=
> TF-8">
> <div>
> <div id=3D"yui_3_16_0_ym19_1_1496345010090_2766">I have noticed
> that we had a broken replication agreement between replica in
> amazon and on another physical node.=C2=A0</div>
> <div id=3D"yui_3_16_0_ym19_1_1496345010090_2729">I have attempted
> to re-initialize but received</div>
> <div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1496345010090_2767"><i
> id=3D"yui_3_16_0_ym19_1_1496345010090_2869">Update failed!
> Status: [2 Replication error acquiring replica: excessive
> clock skew]</i><br>
> </div>
> <div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1496345010090_2778"><br>
> </div>
> <div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1496345010090_2778"><br>
> </div>
> <div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1496345010090_2778">I ha=
> d
> triple verified that time on both is correct and at most
> within seconds of each other.</div>
> <div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1496345010090_2778"><br>
> </div>
> <div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1496345010090_2778">in
> dirsrv logs I get=C2=A0<br>
> </div>
> <div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1496345010090_2817"><i
> id=3D"yui_3_16_0_ym19_1_1496345010090_2861">Excessive clock
> skew from supplier RUV</i></div>
> <div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1496345010090_2818"><i
> id=3D"yui_3_16_0_ym19_1_1496345010090_2863">Unable to acquire
> replica: error: excessive clock skew</i><br>
> </div>
> <div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1496345010090_2818"><i><=
> br>
> </i></div>
> <div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_
> 1496345010090_2818">=C2=A0=
> After
> doing a bit of searching I found this beauty:</div>
> <div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1496345010090_2818"><a
> moz-do-not-send=3D"true"
> href=3D"https://www.redhat.com/archives/freeipa-users/2014-February/msg00=
> 007.html"
> class=3D"" id=3D"yui_3_16_0_ym19_1_1496345010090_2896">https:=
> //www.redhat.com/archives/freeipa-users/2014-February/msg00007.html</a><b=
> r>
> </div>
> <div id=3D"yui_3_16_0_ym19_1_1496345010090_2912"><br>
> </div>
> <div id=3D"yui_3_16_0_ym19_1_1496345010090_2961">The article
> mentions that the time skew might occur due to server being
> virtualied, and I'm =C2=A0wondering if this is applicable to
> Amazon.</div>
> <div id=3D"yui_3_16_0_ym19_1_1496345010090_2961"><br>
> </div>
> <div id=3D"yui_3_16_0_ym19_1_1496345010090_2961">The steps
> mentioned in the article look intrusive (and intimidating) .
> I'm curious what other avenues are available to me to fix
> this?</div>
> <div id=3D"yui_3_16_0_ym19_1_1496345010090_2961" dir=3D"ltr">If I
> blow away the replica and re-set up the new one from scratch
> would that fix the problem.</div>
> <div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1496345010090_2765"><br>
> </div>
> </div>
> <br>
> <fieldset class=3D"mimeAttachmentHeader"></fieldset>
> <br>
> <pre wrap=3D"">_______________________________________________
> FreeIPA-users mailing list -- <a class=3D"moz-txt-link-abbreviated"
> href=3D=
> "mailto:freeipa-users@lists.fedorahosted.org">freeipa-users(a)lists.fedorah=
> osted.org</a>
> To unsubscribe send an email to <a class=3D"moz-txt-link-abbreviated" hre=
> f=3D"mailto:freeipa-users-leave@lists.fedorahosted.org">freeipa-users-lea=
> ve(a)lists.fedorahosted.org</a>
> </pre>
> </blockquote>
> <br>
> <pre class=3D"moz-signature" cols=3D"72">--=20
> Red Hat GmbH, <a class=3D"moz-txt-link-freetext" href=3D"http://www.de.re=
> dhat.com/">http://www.de.redhat.com/</a>, Registered seat: Grasbrunn,=20
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill,=
> Eric Shander</pre>
> </body>
> </html>
>
> --------------090802020609060703090300--
>
> ------------------------------
>
> Date: Fri, 2 Jun 2017 09:52:03 +0000
> From: Sven Kieske <S.Kieske(a)mittwald.de>
> Subject: [Freeipa-users] status of auditd integration on freeipa
> clients
> To: "freeipa-users(a)lists.fedorahosted.org"
> <freeipa-users(a)lists.fedorahosted.org>
> Message-ID: <1496397122.11351.8.camel(a)mittwald.de>
> Content-Type: multipart/signed; micalg=pgp-sha1;
> protocol="application/pgp-signature";
> boundary="=-BLDUS3cjdZxkLqEvtnxZ"
>
> --=-BLDUS3cjdZxkLqEvtnxZ
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> Hi,
>
> I got a question regarding integration of auditd on freeipa clients.
>
> What I want to achieve is full audit logging, like auditd provides, on
> the freeipa clients.
>
> we tried to hook auditd up with the currently deployed ipa via kerberos,
> but had no luck so far.
>
> we tried to reuse the already present kerberos authentication
> to transmit the auditdata in a secure way, but auditd needs the
> principal name to be "host/$hostname@REALM"
> whereas freeipa requires "$foo/$fqdn@REALM", so it seems we can't
> use kerberos tickets from ipa?
>
> (see also this ML Thread:
> https://www.redhat.com/archives/freeipa-users/2014-August/msg00079.html)
>
> it's very sad to see this divergent development, given that both
> projects are heavily developed by redhat, maybe this can get fixed?
> If I can help with this (even if you just need bug reports opened),
> please tell me so.
>
> In the mean time I would like to ask about the status of this project
> page:
>
> https://www.freeipa.org/page/Session_Recording
>
> Is this already implemnted? So far I couldn't find any practical
> examples on how to configure freeipa with auditd on freeipa clients :(
>
> If you know of any other working solution, please share!
>
> Thanks in advance
>
> --=20
> Mit freundlichen Gr=C3=BC=C3=9Fen / Regards
>
> Sven Kieske
>
> Systemadministrator
>
> Mittwald CM Service GmbH & Co. KG
> K=C3=B6nigsberger Stra=C3=9Fe 6
> 32339 Espelkamp
>
> T: +495772 293100
> F: +495772 293333
>
> https://www.mittwald.de
>
> Gesch=C3=A4ftsf=C3=BChrer: Robert Meyer, Maik Behring
>
> St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217
> HRA 6640, AG Bad Oeynhausen
>
> Komplement=C3=A4rin: Robert Meyer Verwaltungs GmbH
> HRB 13260, AG Bad Oeynhausen
>
> --=-BLDUS3cjdZxkLqEvtnxZ
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: This is a digitally signed message part
> Content-Transfer-Encoding: 7bit
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQIcBAABAgAGBQJZMTVCAAoJEMby9TMDAbQRm74P/Ra0GCM0J/Za4QyLna9hAnYB
> zqXS47d69dSvLiGQdi3byxvzUy/WXfrruFYsk4YqbUhYSXiaDn8VY3VQEIlgb8kx
> sQLTWzFZDEs8aw391REuYeJLEtH0QxoLo6X/N5w1wSMvCH/ihJf+i/AUdtG8xmYK
> 1Z2WqUPW2CVjNUWmLi9M1H4xN4fgYD6mJXFkoQ0mfavDMCyDiRmE01/3cuFGDSOM
> qljeSulmwGCaBHwKh3HZFgLrHzWv/ja1/c933FzLVQvW90X+fR4vERCsKzvGP0IB
> 0snHPFk2Tgep3ShR/fR+Nm54WwFQeYomsZiLQJsqI5/n0/9eP4Ia5kBfmSvcgR6C
> U+cDgCLn+zeBOYn8Pq9Dk9AdjDQQIkXSRGKciRfgS26ig6q8J/giobILJN3ChJRf
> MmUEmqwuMdTQbcnpf86heORkoQCekYO5XxSdq6VUlsXtuCAFzd/l8VNcewDejRYN
> IkV4NjvK/8aBYVUTaTXxjBLpJUPYTihAnocdpt7kBmgon01kT5mb4dinmxyOXe0p
> 0FCbQjSD0tcpv0zSe0rqpUs9UthFskSTR2w5AMBoXfGCMC7eBhdwmC6KdYhWS9FS
> bbr3wsYt/mvxRddmfFNalhMAl5L1K6n/oNfSVPMIScXBeUWnmuea3+5WzXrpKp6x
> tsmdESLJNmv0+TUGqdcA
> =pPNW
> -----END PGP SIGNATURE-----
>
> --=-BLDUS3cjdZxkLqEvtnxZ--
>
> ------------------------------
>
> Date: Fri, 02 Jun 2017 08:59:11 -0400
> From: Simo Sorce <simo(a)redhat.com>
> Subject: [Freeipa-users] Re: IPA and CM?
> To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
> Cc: Kat <uncommonkat(a)gmail.com>
> Message-ID: <1496408351.929.96.camel(a)redhat.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Thu, 2017-06-01 at 14:24 -0500, Kat via FreeIPA-users wrote:
> > Hi,
> >
> > I have read several pages on getting IPA and Clouder Manager working
> > together to make nice with Kerberos, however, having an issue
> > following the various steps. When I run through CM set and put the
> > primary account in I run into the classic "Preauth required" and yet,
> > I can kinit the account with no issues, so I am wondering if there
> > are any hints on debugging this? What is typically the cuase of that
> > kind of error?
>
> Kat, does something fail, or are you simply concerned with the error
> showing up in the kdc logs ?
>
> This error is 'expected' in modern kerberos implementations. The
> original krb5 protocol did not use pre-authentication and that made it
> subject to offline dictionary attacks.
> So to "fix" this hole, pre-authentication mechanism were introduced.
>
> The requirement to pre-authenticate is communicated to the client in
> form of a "Preauth required" error. This is to preserve protocol
> compatibility with previous clients and allow a client to discover what
> kind of pre-authentication is allowed by the KDC (the allowed pre-auth
> types list is returned together with the error).
>
> HTH,
> Simo.
>
> ------------------------------
>
> Date: Fri, 02 Jun 2017 10:48:23 -0400
> From: Chris Dagdigian <dag(a)sonsorol.org>
> Subject: [Freeipa-users] new/fresh server can't be setup as replica
> due to "The remote replica has a different database generation ID
> ..."
> To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
> Message-ID: <59317AB7.9030908(a)sonsorol.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi folks,
>
> Related to my posts from earlier in the week. I'm stuck in catch-22 land
> with no seemingly viable way forward ...
>
> I am stuck with 2x IPA masters in different AWS regions that refuse to
> replicate because the topology is disconnected, I can't seem to force
> the re-connect so I'm trying to expand my topology options by building
> new fresh masters from scratch. CentOS 7.3 with fully updated IPA
> software.
>
>
> The fresh replica install fails with a "Local LDAP" error, these seem to
> be the corresponding errors in the /var/log/dirserv logs:
>
>
> [02/Jun/2017:14:29:31.965022647 +0000] 389-Directory/1.3.5.10
> B2017.145.2037 starting up
> [02/Jun/2017:14:29:31.976521839 +0000] default_mr_indexer_create:
> warning - plugin [caseIgnoreIA5Match] does not handle caseExactIA5Match
> [02/Jun/2017:14:29:32.102416271 +0000] slapd started. Listening on All
> Interfaces port 389 for LDAP requests
> [02/Jun/2017:14:29:32.104077504 +0000] Listening on All Interfaces port
> 636 for LDAPS requests
> [02/Jun/2017:14:29:32.105380691 +0000] Listening on
> /var/run/slapd-companyIDM-ORG.socket for LDAPI requests
> [02/Jun/2017:14:29:35.776066609 +0000] NSMMReplicationPlugin -
> agmt="cn=meTodeawilidmp001.companyidm.org" (deawilidmp001:389): The
> remote replica has a different database generation ID than the local
> database. You may have to reinitialize the remote replica, or the local
> replica.
>
>
>
> And here is the output from trying to perform the replica setup:
>
>
> [root@usaeilidmp003 centos]# ipa-replica-install --setup-ca --principal
> admin --admin-password SEKRIT
>
> Configuring client side components
> Using existing certificate '/etc/ipa/ca.crt'.
> Discovery was successful!
> Client hostname: usaeilidmp003.companyidm.org
> Realm: companyIDM.ORG
> DNS Domain: companyidm.org
> IPA Server: deawilidmp001.companyidm.org
> BaseDN: dc=companyidm,dc=org
>
> Skipping synchronizing time with NTP server.
> Enrolled in IPA realm companyIDM.ORG
> Created /etc/ipa/default.conf
> New SSSD config will be created
> Configured sudoers in /etc/nsswitch.conf
> Configured /etc/sssd/sssd.conf
> Configured /etc/krb5.conf for IPA realm companyIDM.ORG
> trying https://deawilidmp001.companyidm.org/ipa/json
> Forwarding 'schema' to json server
> 'https://deawilidmp001.companyidm.org/ipa/json'
> trying https://deawilidmp001.companyidm.org/ipa/session/json
> Forwarding 'ping' to json server
> 'https://deawilidmp001.companyidm.org/ipa/session/json'
> Forwarding 'ca_is_enabled' to json server
> 'https://deawilidmp001.companyidm.org/ipa/session/json'
> Systemwide CA database updated.
> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
> Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
> Forwarding 'host_mod' to json server
> 'https://deawilidmp001.companyidm.org/ipa/session/json'
> SSSD enabled
> Configured /etc/openldap/ldap.conf
> Configured /etc/ssh/ssh_config
> Configured /etc/ssh/sshd_config
> Configuring companyidm.org as NIS domain.
> Client configuration complete.
>
> Run connection check to master
> Connection check OK
> Configuring NTP daemon (ntpd)
> [1/4]: stopping ntpd
> [2/4]: writing configuration
> [3/4]: configuring ntpd to start on boot
> [4/4]: starting ntpd
> Done configuring NTP daemon (ntpd).
> Configuring directory server (dirsrv). Estimated time: 1 minute
> [1/44]: creating directory server user
> [2/44]: creating directory server instance
> [3/44]: updating configuration in dse.ldif
> [4/44]: restarting directory server
> [5/44]: adding default schema
> [6/44]: enabling memberof plugin
> [7/44]: enabling winsync plugin
> [8/44]: configuring replication version plugin
> [9/44]: enabling IPA enrollment plugin
> [10/44]: enabling ldapi
> [11/44]: configuring uniqueness plugin
> [12/44]: configuring uuid plugin
> [13/44]: configuring modrdn plugin
> [14/44]: configuring DNS plugin
> [15/44]: enabling entryUSN plugin
> [16/44]: configuring lockout plugin
> [17/44]: configuring topology plugin
> [18/44]: creating indices
> [19/44]: enabling referential integrity plugin
> [20/44]: configuring certmap.conf
> [21/44]: configure autobind for root
> [22/44]: configure new location for managed entries
> [23/44]: configure dirsrv ccache
> [24/44]: enabling SASL mapping fallback
> [25/44]: restarting directory server
> [26/44]: creating DS keytab
> [27/44]: retrieving DS Certificate
> [28/44]: restarting directory server
> [29/44]: setting up initial replication
> Starting replication, please wait until this has completed.
> Update in progress, 15 seconds elapsed
> [deawilidmp001.companyidm.org] reports: Update failed! Status: [-2 -
> LDAP error: Local error]
>
> [error] RuntimeError: Failed to start replication
> Your system may be partly configured.
> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>
> ipa.ipapython.install.cli.install_tool(Replica): ERROR Failed to
> start replication
> ipa.ipapython.install.cli.install_tool(Replica): ERROR The
> ipa-replica-install command failed. See /var/log/ipareplica-install.log
> for more information
> [root@usaeilidmp003 centos]#
>
> \
>
> ------------------------------
>
> Date: Fri, 2 Jun 2017 09:04:37 -0600
> From: "Jose Alvarez R." <jalvarez(a)cyberfuel.com>
> Subject: [Freeipa-users] Re: DatabaseError: Server is unwilling to
> perform: Too many failed logins.
> To: "'FreeIPA users list'" <freeipa-users(a)lists.fedorahosted.org>
> Cc: 'Rob Crittenden' <rcritten(a)redhat.com>
> Message-ID: <023101d2dbb1$8d3ec080$a7bc4180$(a)cyberfuel.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi Rob
>
> Thanks for your response
>
> Well, the source error is Internal Server Error 500 and this happened when
> I was surfing the UI website.
>
> A forum talks about the problem and show these same mistakes.
>
> [root@ipa ipa_memcached]# cat /var/log/httpd/error_log* | grep
> var/run/ipa_memcached/
> [Sun May 28 06:40:51.725678 2017] [wsgi:error] [pid 25441] ipa: ERROR:
> release_ipa_ccache: ccache_name (FILE:/var/run/ipa_memcached/krbcc_25441)
> != KRB5CCNAME environment variable (/var/run/httpd/ipa/krbcache/
> krb5ccache)
> [Mon May 29 08:33:47.909256 2017] [wsgi:error] [pid 30951] ipa: ERROR:
> release_ipa_ccache: ccache_name (FILE:/var/run/ipa_memcached/krbcc_30951)
> != KRB5CCNAME environment variable (/var/run/httpd/ipa/krbcache/
> krb5ccache)
> [Wed May 31 11:20:33.216853 2017] [wsgi:error] [pid 2024] ipa: ERROR:
> release_ipa_ccache: ccache_name (FILE:/var/run/ipa_memcached/krbcc_2024)
> != KRB5CCNAME environment variable (/var/run/httpd/ipa/krbcache/
> krb5ccache)
> [Wed May 31 14:58:20.765378 2017] [wsgi:error] [pid 2638] ipa: ERROR:
> release_ipa_ccache: ccache_name (FILE:/var/run/ipa_memcached/krbcc_2638)
> != KRB5CCNAME environment variable (/var/run/httpd/ipa/krbcache/
> krb5ccache)
> [Sun May 14 10:37:26.328760 2017] [wsgi:error] [pid 14689] ipa: ERROR:
> release_ipa_ccache: ccache_name (FILE:/var/run/ipa_memcached/krbcc_14689)
> != KRB5CCNAME environment variable (/var/run/httpd/ipa/krbcache/
> krb5ccache)
> [Mon May 15 10:52:54.329041 2017] [wsgi:error] [pid 15684] ipa: ERROR:
> release_ipa_ccache: ccache_name (FILE:/var/run/ipa_memcached/krbcc_15684)
> != KRB5CCNAME environment variable (/var/run/httpd/ipa/krbcache/
> krb5ccache)
> [Sun May 21 08:24:44.796135 2017] [wsgi:error] [pid 21336] ipa: ERROR:
> release_ipa_ccache: ccache_name (FILE:/var/run/ipa_memcached/krbcc_21336)
> != KRB5CCNAME environment variable (/var/run/httpd/ipa/krbcache/
> krb5ccache)
> [Sun May 21 09:06:47.160491 2017] [wsgi:error] [pid 22286] ipa: ERROR:
> release_ipa_ccache: ccache_name (FILE:/var/run/ipa_memcached/krbcc_22286)
> != KRB5CCNAME environment variable (/var/run/httpd/ipa/krbcache/
> krb5ccache)
> [Mon May 22 08:08:36.230187 2017] [wsgi:error] [pid 1172] ipa: ERROR:
> release_ipa_ccache: ccache_name (FILE:/var/run/ipa_memcached/krbcc_1172)
> != KRB5CCNAME environment variable (/var/run/httpd/ipa/krbcache/
> krb5ccache)
> [Mon May 22 09:46:18.902093 2017] [wsgi:error] [pid 18385] ipa: ERROR:
> release_ipa_ccache: ccache_name (FILE:/var/run/ipa_memcached/krbcc_18385)
> != KRB5CCNAME environment variable (/var/run/httpd/ipa/krbcache/
> krb5ccache)
> [Thu May 25 11:17:44.614808 2017] [wsgi:error] [pid 17917] ipa: ERROR:
> release_ipa_ccache: ccache_name (FILE:/var/run/ipa_memcached/krbcc_17917)
> != KRB5CCNAME environment variable (/var/run/httpd/ipa/krbcache/
> krb5ccache)
> [Fri May 26 06:47:28.370299 2017] [wsgi:error] [pid 19054] ipa: ERROR:
> release_ipa_ccache: ccache_name (FILE:/var/run/ipa_memcached/krbcc_19054)
> != KRB5CCNAME environment variable (/var/run/httpd/ipa/krbcache/
> krb5ccache)
> [Fri May 26 09:47:38.076514 2017] [wsgi:error] [pid 21824] ipa: ERROR:
> release_ipa_ccache: ccache_name (FILE:/var/run/ipa_memcached/krbcc_21824)
> != KRB5CCNAME environment variable (/var/run/httpd/ipa/krbcache/
> krb5ccache)
> [Fri May 26 10:58:15.032141 2017] [wsgi:error] [pid 22569] ipa: ERROR:
> release_ipa_ccache: ccache_name (FILE:/var/run/ipa_memcached/krbcc_22569)
> != KRB5CCNAME environment variable (/var/run/httpd/ipa/krbcache/
> krb5ccache)
>
>
> Error is not by login
>
>
> Thanks, Regards
>
> Jose Alvarez
>
>
> -----Original Message-----
> From: Rob Crittenden via FreeIPA-users [mailto:freeipa-users@lists.
> fedorahosted.org]
> Sent: jueves 1 de junio de 2017 03:05 p.m.
> To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
> Cc: Jose Alvarez R. <jalvarez(a)cyberfuel.com>; Rob Crittenden <
> rcritten(a)redhat.com>
> Subject: [Freeipa-users] Re: DatabaseError: Server is unwilling to
> perform: Too many failed logins.
>
> Jose Alvarez R. via FreeIPA-users wrote:
> > Hi
> >
> >
> >
> > Can you help me with this problem?
> >
> >
> >
> > My FreeIPA version 4.3.3 and the S.O. is Fedora 24
>
> It would help if you'd provide context to what you were doing at the time.
>
> A account may be locked out for a period of time due to too many failed
> authentication requests.
>
> rob
>
> >
> >
> >
> > Thanks Regards
> >
> >
> >
> > Jose Alvarez
> >
> >
> >
> >
> >
> >
> >
> > *From:*Jose Alvarez R. [mailto:jalvarez@cyberfuel.com]
> > *Sent:* miércoles 31 de mayo de 2017 12:17 p.m.
> > *To:* 'FreeIPA users list' <freeipa-users(a)lists.fedorahosted.org>
> > *Subject:* DatabaseError: Server is unwilling to perform: Too many
> > failed logins.
> >
> >
> >
> > Hi
> >
> >
> >
> > A question, I have the following errors on my server FreeIPA 4.3.3
> >
> >
> >
> >
> >
> > cat /var/log/httpd/error_log
> >
> >
> >
> >
> >
> > Wed May 31 11:27:59.079315 2017] [wsgi:error] [pid 2024] [remote
> > 192.168.0.114:200] mod_wsgi (pid=2024): Exception occurred processing
> > WSGI script '/usr/share/ipa/wsgi
> >
> > [Wed May 31 11:27:59.079432 2017] [wsgi:error] [pid 2024] [remote
> > 192.168.0.114:200] Traceback (most recent call last):
> >
> > [Wed May 31 11:27:59.079486 2017] [wsgi:error] [pid 2024] [remote
> > 192.168.0.114:200] File "/usr/share/ipa/wsgi.py", line 63, in
> application
> >
> > [Wed May 31 11:27:59.079675 2017] [wsgi:error] [pid 2024] [remote
> > 192.168.0.114:200] return api.Backend.wsgi_dispatch(environ,
> > start_response)
> >
> > [Wed May 31 11:27:59.079703 2017] [wsgi:error] [pid 2024] [remote
> > 192.168.0.114:200] File
> > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 261,
> > in __ca
> >
> > [Wed May 31 11:27:59.080261 2017] [wsgi:error] [pid 2024] [remote
> > 192.168.0.114:200] return self.route(environ, start_response)
> >
> > [Wed May 31 11:27:59.080298 2017] [wsgi:error] [pid 2024] [remote
> > 192.168.0.114:200] File
> > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 273,
> > in rout
> >
> > [Wed May 31 11:27:59.080343 2017] [wsgi:error] [pid 2024] [remote
> > 192.168.0.114:200] return app(environ, start_response)
> >
> > [Wed May 31 11:27:59.080401 2017] [wsgi:error] [pid 2024] [remote
> > 192.168.0.114:200] File
> > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 811,
> > in __ca
> >
> > [Wed May 31 11:27:59.080437 2017] [wsgi:error] [pid 2024] [remote
> > 192.168.0.114:200] self.create_context(ccache=ipa_ccache_name)
> >
> > [Wed May 31 11:27:59.080455 2017] [wsgi:error] [pid 2024] [remote
> > 192.168.0.114:200] File
> > "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 123, in
> > create_co
> >
> > [Wed May 31 11:27:59.080578 2017] [wsgi:error] [pid 2024] [remote
> > 192.168.0.114:200] self.Backend.ldap2.connect(ccache=ccache)
> >
> > [Wed May 31 11:27:59.080611 2017] [wsgi:error] [pid 2024] [remote
> > 192.168.0.114:200] File
> > "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 66, in
> > connect
> >
> > [Wed May 31 11:27:59.080654 2017] [wsgi:error] [pid 2024] [remote
> > 192.168.0.114:200] conn = self.create_connection(*args, **kw)
> >
> > [Wed May 31 11:27:59.080691 2017] [wsgi:error] [pid 2024] [remote
> > 192.168.0.114:200] File
> > "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line
> > 202, in
> >
> > [Wed May 31 11:27:59.080973 2017] [wsgi:error] [pid 2024] [remote
> > 192.168.0.114:200] client_controls=clientctrls)
> >
> > [Wed May 31 11:27:59.081019 2017] [wsgi:error] [pid 2024] [remote
> > 192.168.0.114:200] File
> > "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1085, in
> > gssap
> >
> > [Wed May 31 11:27:59.081653 2017] [wsgi:error] [pid 2024] [remote
> > 192.168.0.114:200] '', auth_tokens, server_controls,
> client_controls)
> >
> > [Wed May 31 11:27:59.081678 2017] [wsgi:error] [pid 2024] [remote
> > 192.168.0.114:200] File "/usr/lib64/python2.7/contextlib.py", line 35,
> > in __exit__
> >
> > [Wed May 31 11:27:59.081835 2017] [wsgi:error] [pid 2024] [remote
> > 192.168.0.114:200] self.gen.throw(type, value, traceback)
> >
> > [Wed May 31 11:27:59.081897 2017] [wsgi:error] [pid 2024] [remote
> > 192.168.0.114:200] File
> > "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 998, in
> > error_
> >
> > [Wed May 31 11:27:59.081955 2017] [wsgi:error] [pid 2024] [remote
> > 192.168.0.114:200] raise errors.DatabaseError(desc=desc, info=info)
> >
> > [Wed May 31 11:27:59.082028 2017] [wsgi:error] [pid 2024] [remote
> > 192.168.0.114:200] DatabaseError: Server is unwilling to perform: Too
> > many failed logins.
> >
> >
> >
> > I checked this link: https://pagure.io/freeipa/issue/5653
> >
> >
> >
> > But I'm not sure, How can I solve that?
> >
> >
> >
> > Thanks, Regards
> >
> >
> >
> >
> >
> > Jose Alvarez
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> > To unsubscribe send an email to
> > freeipa-users-leave(a)lists.fedorahosted.org
> >
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>
> ------------------------------
>
> Date: Fri, 2 Jun 2017 10:10:26 -0500
> From: Kat <uncommonkat(a)gmail.com>
> Subject: [Freeipa-users] Re: IPA and CM?
> To: Simo Sorce <simo(a)redhat.com>, FreeIPA users list
> <freeipa-users(a)lists.fedorahosted.org>
> Message-ID: <484a0111-7e87-0dac-2be1-2e4df5e6aeb2(a)gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi Simo,
>
> I understand the mechanics of the error, however, when you are trying to
> configure Cloudera Manager with IPA, the configuration/setup process
> fails with the error (and it shows in logs) and therefore, CM does not
> finish the configuration.
>
> I was also just reading:
> https://community.cloudera.com/t5/Cloudera-Manager-
> Installation/Add-Support-for-FreeIPA-to-CM/td-p/34582
>
> Which has Dmitri discussing things with Cloudera. The problem seems to
> be that although CM has a script for custom principal retrievals, maybe
> what I am seeing here is that it is the ipa-client install that causes
> the problems? Or am I missing the boat completely?
>
> -K
>
>
> On 6/2/17 7:59 AM, Simo Sorce wrote:
> > On Thu, 2017-06-01 at 14:24 -0500, Kat via FreeIPA-users wrote:
> >> Hi,
> >>
> >> I have read several pages on getting IPA and Clouder Manager working
> >> together to make nice with Kerberos, however, having an issue
> >> following the various steps. When I run through CM set and put the
> >> primary account in I run into the classic "Preauth required" and yet,
> >> I can kinit the account with no issues, so I am wondering if there
> >> are any hints on debugging this? What is typically the cuase of that
> >> kind of error?
> > Kat, does something fail, or are you simply concerned with the error
> > showing up in the kdc logs ?
> >
> > This error is 'expected' in modern kerberos implementations. The
> > original krb5 protocol did not use pre-authentication and that made it
> > subject to offline dictionary attacks.
> > So to "fix" this hole, pre-authentication mechanism were introduced.
> >
> > The requirement to pre-authenticate is communicated to the client in
> > form of a "Preauth required" error. This is to preserve protocol
> > compatibility with previous clients and allow a client to discover what
> > kind of pre-authentication is allowed by the KDC (the allowed pre-auth
> > types list is returned together with the error).
> >
> > HTH,
> > Simo.
>
> ------------------------------
>
> Date: Fri, 02 Jun 2017 11:25:36 -0400
> From: Simo Sorce <simo(a)redhat.com>
> Subject: [Freeipa-users] Re: IPA and CM?
> To: Kat <uncommonkat(a)gmail.com>, FreeIPA users list
> <freeipa-users(a)lists.fedorahosted.org>
> Message-ID: <1496417136.929.102.camel(a)redhat.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Fri, 2017-06-02 at 10:10 -0500, Kat wrote:
> > Hi Simo,
> >
> > I understand the mechanics of the error, however, when you are trying
> > to configure Cloudera Manager with IPA, the configuration/setup
> > process fails with the error (and it shows in logs) and therefore, CM
> > does not finish the configuration.
>
> I am not familiar with clouders, if it depends on the kadmin interface,
> then it will not work as in FreeIPA thatintrerface is read-only.
>
> If the only issue is using a keytab where they use some old kerberos
> component that does not handle preauthenticated encryption, then you
> can go into freeipa and lift the requirement to perform
> preauthentication for that specific principal.
>
> ipa service-mod my/principal@REALM --requires-pre-auth=false
>
> HTH,
> Simo.
>
> > I was also just reading:
> > https://community.cloudera.com/t5/Cloudera-Manager-Installation/Add-S
> > upport-for-FreeIPA-to-CM/td-p/34582
> >
> > Which has Dmitri discussing things with Cloudera. The problem seems
> > to be that although CM has a script for custom principal retrievals,
> > maybe what I am seeing here is that it is the ipa-client install
> > that causes the problems? Or am I missing the boat completely?
> >
> > -K
> >
> >
> > On 6/2/17 7:59 AM, Simo Sorce wrote:
> > > On Thu, 2017-06-01 at 14:24 -0500, Kat via FreeIPA-users wrote:
> > > > Hi,
> > > >
> > > > I have read several pages on getting IPA and Clouder Manager
> > > > working
> > > > together to make nice with Kerberos, however, having an issue
> > > > following the various steps. When I run through CM set and put
> > > > the
> > > > primary account in I run into the classic "Preauth required" and
> > > > yet,
> > > > I can kinit the account with no issues, so I am wondering if
> > > > there
> > > > are any hints on debugging this? What is typically the cuase of
> > > > that
> > > > kind of error?
> > >
> > > Kat, does something fail, or are you simply concerned with the
> > > error
> > > showing up in the kdc logs ?
> > >
> > > This error is 'expected' in modern kerberos implementations. The
> > > original krb5 protocol did not use pre-authentication and that made
> > > it
> > > subject to offline dictionary attacks.
> > > So to "fix" this hole, pre-authentication mechanism were
> > > introduced.
> > >
> > > The requirement to pre-authenticate is communicated to the client
> > > in
> > > form of a "Preauth required" error. This is to preserve protocol
> > > compatibility with previous clients and allow a client to discover
> > > what
> > > kind of pre-authentication is allowed by the KDC (the allowed pre-
> > > auth
> > > types list is returned together with the error).
> > >
> > > HTH,
> > > Simo.
> >
> >
>
> ------------------------------
>
> Date: Fri, 2 Jun 2017 18:34:45 +0300
> From: Alexander Bokovoy <abokovoy(a)redhat.com>
> Subject: [Freeipa-users] Re: IPA and CM?
> To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
> Cc: Kat <uncommonkat(a)gmail.com>
> Message-ID: <20170602153445.qhu4rttqkqrfrmor(a)redhat.com>
> Content-Type: text/plain; charset=iso-8859-1; format=flowed
>
> On pe, 02 kesä 2017, Simo Sorce via FreeIPA-users wrote:
> >On Fri, 2017-06-02 at 10:10 -0500, Kat wrote:
> >> Hi Simo,
> >>
> >> I understand the mechanics of the error, however, when you are trying
> >> to configure Cloudera Manager with IPA, the configuration/setup
> >> process fails with the error (and it shows in logs) and therefore, CM
> >> does not finish the configuration.
> >
> >I am not familiar with clouders, if it depends on the kadmin interface,
> >then it will not work as in FreeIPA thatintrerface is read-only.
> >
> >If the only issue is using a keytab where they use some old kerberos
> >component that does not handle preauthenticated encryption, then you
> >can go into freeipa and lift the requirement to perform
> >preauthentication for that specific principal.
> >
> >ipa service-mod my/principal@REALM --requires-pre-auth=false
> I did already refer to this blogpost the other week:
> https://mapredit.blogspot.fi/2016/10/freeipa-and-hadoop-
> distributions-hdp-cdh.html
>
> --
> / Alexander Bokovoy
>
> ------------------------------
>
> Date: Fri, 2 Jun 2017 13:10:04 -0400
> From: Striker Leggette <striker(a)terranforge.com>
> Subject: [Freeipa-users] FreeIPA for simply managing DNS
> To: freeipa-users(a)redhat.com
> Message-ID: <6f3803ff-6052-5f3a-3b57-b63d4b51f786(a)terranforge.com>
> Content-Type: multipart/alternative;
> boundary="------------2E0C330E1EE2AA61A1B67AAF"
>
> This is a multi-part message in MIME format.
> --------------2E0C330E1EE2AA61A1B67AAF
> Content-Type: text/plain; charset=utf-8; format=flowed
> Content-Transfer-Encoding: 7bit
>
> FreeIPA has a very well-made and easy to use DNS management GUI that
> would serve well as a standalone tool. Are there any plans to fork the
> DNS GUI like this for those who would like an easy DNS management
> application who do not necessarily need LDAP/PKI/Kerberos/etc.?
>
> --
> Striker Leggette
> Identity Management
>
> linkedin.com/in/striker
>
>
> --------------2E0C330E1EE2AA61A1B67AAF
> Content-Type: text/html; charset=utf-8
> Content-Transfer-Encoding: quoted-printable
>
> <html>
> <head>
>
> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf=
> -8">
> </head>
> <body text=3D"#000000" bgcolor=3D"#FFFFFF">
> <p><tt><font size=3D"-1">FreeIPA has a very well-made and easy to use
> DNS management GUI that would serve well as a standalone
> tool.=C2=A0 Are there any plans to fork the DNS GUI like this f=
> or
> those who would like an easy DNS management application who do
> not necessarily need LDAP/PKI/Kerberos/etc.?</font></tt><br>
> </p>
> <pre class=3D"moz-signature" cols=3D"72">--=20
> Striker Leggette
> Identity Management
>
> linkedin.com/in/striker</pre>
> </body>
> </html>
>
> --------------2E0C330E1EE2AA61A1B67AAF--
>
> ------------------------------
>
> Date: Fri, 2 Jun 2017 10:21:47 -0700
> From: Devin Acosta <linuxguru.co(a)gmail.com>
> Subject: [Freeipa-users] FreeIPA (adding all new users to admin group
> by default?)
> To: freeipa-users(a)lists.fedorahosted.org
> Message-ID:
> <CAAqg8ePTEzbH5CqOrSooMZcQRDF18Ajw-J12gvfnBU7QApM9kw@mail.
> gmail.com>
> Content-Type: multipart/alternative;
> boundary="001a113e3aba5c916f0550fd638e"
>
> --001a113e3aba5c916f0550fd638e
> Content-Type: text/plain; charset="UTF-8"
>
> I am hoping to see if someone can tell me what I either need to change or
> update to get it so that FreeIPA doesn't automatically keep adding all new
> users that is created automatically to the admin group. I inherited this
> installation of FreeIPA and so far haven't been able to figure out what
> either got changed or how to disable this behavior? I am running the latest
> FreeIPA 4.4 on CentOS 7.3.
>
> Any help would be greatly appreciated.
>
> Devin Acosta
>
> --001a113e3aba5c916f0550fd638e
> Content-Type: text/html; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> <div dir=3D"ltr"><br><div>I am hoping to see if someone can tell me what I
> =
> either need to change or update to get it so that FreeIPA doesn't
> autom=
> atically keep adding all new users that is created automatically to the
> adm=
> in group. I inherited this installation of FreeIPA and so far haven't
> b=
> een able to figure out what either got changed or how to disable this
> behav=
> ior? I am running the latest FreeIPA 4.4 on CentOS
> 7.3.</div><div><br></div=
> ><div>Any help would be greatly appreciated.</div><div><br></
> div><div>Devin=
> Acosta</div></div>
>
> --001a113e3aba5c916f0550fd638e--
>
> ------------------------------
>
> Date: Fri, 2 Jun 2017 14:02:03 -0400
> From: Rob Crittenden <rcritten(a)redhat.com>
> Subject: [Freeipa-users] Re: FreeIPA (adding all new users to admin
> group by default?)
> To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
> Cc: Devin Acosta <linuxguru.co(a)gmail.com>
> Message-ID: <4bc6e614-0f53-c177-848d-a574e0cb0b15(a)redhat.com>
> Content-Type: text/plain; charset=UTF-8
>
> Devin Acosta via FreeIPA-users wrote:
> >
> > I am hoping to see if someone can tell me what I either need to change
> > or update to get it so that FreeIPA doesn't automatically keep adding
> > all new users that is created automatically to the admin group. I
> > inherited this installation of FreeIPA and so far haven't been able to
> > figure out what either got changed or how to disable this behavior? I am
> > running the latest FreeIPA 4.4 on CentOS 7.3.
> >
> > Any help would be greatly appreciated.
>
> Probably the default users group. Try:
>
> $ kinit admin
> $ ipa config-show |grep 'Default users group'
>
> Can be changed using:
>
> $ ipa config-mod --defaultgroup ipausers
>
> You can probably do this in the UI as well but I'm a CLI guy.
>
> rob
>
> ------------------------------
>
> Date: Fri, 2 Jun 2017 11:12:35 -0700
> From: Devin Acosta <linuxguru.co(a)gmail.com>
> Subject: [Freeipa-users] Re: FreeIPA (adding all new users to admin
> group by default?)
> To: Rob Crittenden <rcritten(a)redhat.com>
> Cc: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
> Message-ID:
> <CAAqg8eMzKRjO3ZNkOmiN=9cVD_B-voRNcmwbaesGifSyjEU+sw@mail.
> gmail.com>
> Content-Type: multipart/alternative;
> boundary="94eb2c04fa92075a9e0550fe1901"
>
> --94eb2c04fa92075a9e0550fe1901
> Content-Type: text/plain; charset="UTF-8"
>
> Rob,
>
> That is what confuses me, I show that the default users group is
> "ipausers", however when I added an account which I just tested it added to
> admins group. Anything else that could be making it add it to the "admin"
> group?
>
> [root@ipa01 ~]# ipa config-show
> Maximum username length: 32
> Home directory base: /home
> Default shell: /bin/bash
> * Default users group: ipausers*
> Default e-mail domain: m451.tech
> Search time limit: 2
> Search size limit: -1
> User search fields: uid,givenname,sn,telephonenumber,ou,title
> Group search fields: cn,description
> Enable migration mode: FALSE
> Certificate Subject base: O=M451.TECH
> Password Expiration Notification (days): 4
> Password plugin features: AllowNThash
> SELinux user map order:
> guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$
> unconfined_u:s0-s0:c0.c1023
> Default SELinux user: unconfined_u:s0-s0:c0.c1023
> Default PAC types: nfs:NONE, MS-PAC
>
> [root@ipa01 ~]# ipa user-add testuser-devin
> First name: Devin
> Last name: Acosta
> ---------------------------
> Added user "testuser-devin"
> ---------------------------
> User login: testuser-devin
> First name: Devin
> Last name: Acosta
> Full name: Devin Acosta
> Display name: Devin Acosta
> Initials: DA
> Home directory: /home/testuser-devin
> GECOS: Devin Acosta
> Login shell: /bin/bash
> Principal name: testuser-devin(a)M451.TECH
> Principal alias: testuser-devin(a)M451.TECH
> Email address: testuser-devin(a)m451.tech
> UID: 34375527
> GID: 34375527
> Password: False
> *Member of groups: ipausers, admins*
> Roles: IT Security Specialist, sec_netops2, helpdesk, IT Specialist, User
> Administrator, Security Architect, ipa_join
> Indirect Member of role: ipa_join, helpdesk, IT Security Specialist,
> sec_netops2, IT Specialist, Security Architect, User Administrator
> Kerberos keys available: False
>
> On Fri, Jun 2, 2017 at 11:02 AM, Rob Crittenden <rcritten(a)redhat.com>
> wrote:
>
> > Devin Acosta via FreeIPA-users wrote:
> > >
> > > I am hoping to see if someone can tell me what I either need to change
> > > or update to get it so that FreeIPA doesn't automatically keep adding
> > > all new users that is created automatically to the admin group. I
> > > inherited this installation of FreeIPA and so far haven't been able to
> > > figure out what either got changed or how to disable this behavior? I
> am
> > > running the latest FreeIPA 4.4 on CentOS 7.3.
> > >
> > > Any help would be greatly appreciated.
> >
> > Probably the default users group. Try:
> >
> > $ kinit admin
> > $ ipa config-show |grep 'Default users group'
> >
> > Can be changed using:
> >
> > $ ipa config-mod --defaultgroup ipausers
> >
> > You can probably do this in the UI as well but I'm a CLI guy.
> >
> > rob
> >
>
> --94eb2c04fa92075a9e0550fe1901
> Content-Type: text/html; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> <div dir=3D"ltr"><br><div>Rob,</div><div><br></div><div>That is what
> confus=
> es me, I show that the default users group is "ipausers",
> however=
> when I added an account which I just tested it added to admins group.=C2=
> =A0 Anything else that could be making it add it to the "admin"
> g=
> roup?</div><div><br></div><div><div>[root@ipa01 ~]# ipa
> config-show</div><d=
> iv>=C2=A0 Maximum username length: 32</div><div>=C2=A0 Home directory
> base:=
> /home</div><div>=C2=A0 Default shell: /bin/bash</div><div><b>=C2=A0
> Defaul=
> t users group: ipausers</b></div><div>=C2=A0 Default e-mail domain:
> m451.te=
> ch</div><div>=C2=A0 Search time limit: 2</div><div>=C2=A0 Search size
> limit=
> : -1</div><div>=C2=A0 User search fields: uid,givenname,sn,
> telephonenumber,=
> ou,title</div><div>=C2=A0 Group search fields:
> cn,description</div><div>=C2=
> =A0 Enable migration mode: FALSE</div><div>=C2=A0 Certificate Subject
> base:=
> O=3DM451.TECH</div><div>=C2=A0 Password Expiration Notification (days):
> 4<=
> /div><div>=C2=A0 Password plugin features: AllowNThash</div><div>=C2=A0
> SEL=
> inux user map order: guest_u:s0$xguest_u:s0$user_u:
> s0$staff_u:s0-s0:c0.c102=
> 3$unconfined_u:s0-s0:c0.c1023</div><div>=C2=A0 Default SELinux user:
> unconf=
> ined_u:s0-s0:c0.c1023</div><div>=C2=A0 Default PAC types: nfs:NONE,
> MS-PAC<=
> /div></div><div><br></div><div><div>[root@ipa01 ~]# ipa user-add
> testuser-d=
> evin</div><div>First name: Devin</div><div>Last name:
> Acosta</div><div>----=
> -----------------------</div><div>Added user "testuser-devin"</
> di=
> v><div>---------------------------</div><div>=C2=A0 User login:
> testuser-de=
> vin</div><div>=C2=A0 First name: Devin</div><div>=C2=A0 Last name:
> Acosta</=
> div><div>=C2=A0 Full name: Devin Acosta</div><div>=C2=A0 Display name:
> Devi=
> n Acosta</div><div>=C2=A0 Initials: DA</div><div>=C2=A0 Home directory:
> /ho=
> me/testuser-devin</div><div>=C2=A0 GECOS: Devin Acosta</div><div>=C2=A0
> Log=
> in shell: /bin/bash</div><div>=C2=A0 Principal name: testuser-devin(a)M451.TE
> =
> CH</div><div>=C2=A0 Principal alias: testuser-devin(a)M451.TECH</div>
> <div>=C2=
> =A0 Email address: testuser-devin(a)m451.tech</div><div>=C2=A0 UID:
> 34375527<=
> /div><div>=C2=A0 GID: 34375527</div><div>=C2=A0 Password: False</div><div>=
> =C2=A0 <b>Member of groups: ipausers, admins</b></div><div>=C2=A0 Roles:
> IT=
> Security Specialist, sec_netops2, helpdesk, IT Specialist, User
> Administra=
> tor, Security Architect, ipa_join</div><div>=C2=A0 Indirect Member of
> role:=
> ipa_join, helpdesk, IT Security Specialist, sec_netops2, IT Specialist,
> Se=
> curity Architect, User Administrator</div><div>=C2=A0 Kerberos keys
> availab=
> le: False</div></div></div><div class=3D"gmail_extra"><br><div
> class=3D"gma=
> il_quote">On Fri, Jun 2, 2017 at 11:02 AM, Rob Crittenden <span
> dir=3D"ltr"=
> ><<a href=3D"mailto:rcritten@redhat.com" target=3D"_blank">rcritten@
> redh=
> at.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote"
> style=3D"=
> margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
> =3D"">Devin Acosta via FreeIPA-users wrote:<br>
> ><br>
> > I am hoping to see if someone can tell me what I either need to
> change=
> <br>
> > or update to get it so that FreeIPA doesn't automatically keep
> add=
> ing<br>
> > all new users that is created automatically to the admin group. I<br>
> > inherited this installation of FreeIPA and so far haven't been
> abl=
> e to<br>
> > figure out what either got changed or how to disable this behavior? I
> =
> am<br>
> > running the latest FreeIPA 4.4 on CentOS 7.3.<br>
> ><br>
> > Any help would be greatly appreciated.<br>
> <br>
> </span>Probably the default users group. Try:<br>
> <br>
> $ kinit admin<br>
> $ ipa config-show |grep 'Default users group'<br>
> <br>
> Can be changed using:<br>
> <br>
> $ ipa config-mod --defaultgroup ipausers<br>
> <br>
> You can probably do this in the UI as well but I'm a CLI guy.<br>
> <span class=3D"HOEnZb"><font color=3D"#888888"><br>
> rob<br>
> </font></span></blockquote></div><br></div>
>
> --94eb2c04fa92075a9e0550fe1901--
>
> ------------------------------
>
> Date: Fri, 2 Jun 2017 18:20:52 +0000
> From: <wouter.hummelink(a)kpn.com>
> Subject: [Freeipa-users] Re: FreeIPA (adding all new users to admin
> group by default?)
> To: <freeipa-users(a)lists.fedorahosted.org>, <rcritten(a)redhat.com>
> Cc: linuxguru.co(a)gmail.com
> Message-ID: <wr5vefergmq3fe5uuk63b7cn.1496427649570(a)email.android.com>
> Content-Type: multipart/alternative;
> boundary="_000_wr5vefergmq3fe5uuk63b7cn149642
> 7649570emailandroidcom_"
>
> --_000_wr5vefergmq3fe5uuk63b7cn1496427649570emailandroidcom_
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> Look at automember rules.
>
>
>
> Verzonden vanaf mijn Samsung-apparaat
>
>
> -------- Oorspronkelijk bericht --------
> Van: Devin Acosta via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org>
> Datum: 02-06-17 20:13 (GMT+01:00)
> Aan: Rob Crittenden <rcritten(a)redhat.com>
> Cc: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>, Devin
> Acosta=
> <linuxguru.co(a)gmail.com>
> Onderwerp: [Freeipa-users] Re: FreeIPA (adding all new users to admin
> group=
> by default?)
>
>
> Rob,
>
> That is what confuses me, I show that the default users group is
> "ipausers"=
> , however when I added an account which I just tested it added to admins
> gr=
> oup. Anything else that could be making it add it to the "admin" group?
>
> [root@ipa01 ~]# ipa config-show
> Maximum username length: 32
> Home directory base: /home
> Default shell: /bin/bash
> Default users group: ipausers
> Default e-mail domain: m451.tech
> Search time limit: 2
> Search size limit: -1
> User search fields: uid,givenname,sn,telephonenumber,ou,title
> Group search fields: cn,description
> Enable migration mode: FALSE
> Certificate Subject base: O=3DM451.TECH
> Password Expiration Notification (days): 4
> Password plugin features: AllowNThash
> SELinux user map order: guest_u:s0$xguest_u:s0$user_u:
> s0$staff_u:s0-s0:c0=
> .c1023$unconfined_u:s0-s0:c0.c1023
> Default SELinux user: unconfined_u:s0-s0:c0.c1023
> Default PAC types: nfs:NONE, MS-PAC
>
> [root@ipa01 ~]# ipa user-add testuser-devin
> First name: Devin
> Last name: Acosta
> ---------------------------
> Added user "testuser-devin"
> ---------------------------
> User login: testuser-devin
> First name: Devin
> Last name: Acosta
> Full name: Devin Acosta
> Display name: Devin Acosta
> Initials: DA
> Home directory: /home/testuser-devin
> GECOS: Devin Acosta
> Login shell: /bin/bash
> Principal name: testuser-devin(a)M451.TECH
> Principal alias: testuser-devin(a)M451.TECH
> Email address: testuser-devin(a)m451.tech
> UID: 34375527
> GID: 34375527
> Password: False
> Member of groups: ipausers, admins
> Roles: IT Security Specialist, sec_netops2, helpdesk, IT Specialist,
> User=
> Administrator, Security Architect, ipa_join
> Indirect Member of role: ipa_join, helpdesk, IT Security Specialist,
> sec_=
> netops2, IT Specialist, Security Architect, User Administrator
> Kerberos keys available: False
>
> On Fri, Jun 2, 2017 at 11:02 AM, Rob Crittenden <rcritten(a)redhat.com
> <mailto=
> :rcritten@redhat.com>> wrote:
> Devin Acosta via FreeIPA-users wrote:
> >
> > I am hoping to see if someone can tell me what I either need to change
> > or update to get it so that FreeIPA doesn't automatically keep adding
> > all new users that is created automatically to the admin group. I
> > inherited this installation of FreeIPA and so far haven't been able to
> > figure out what either got changed or how to disable this behavior? I am
> > running the latest FreeIPA 4.4 on CentOS 7.3.
> >
> > Any help would be greatly appreciated.
>
> Probably the default users group. Try:
>
> $ kinit admin
> $ ipa config-show |grep 'Default users group'
>
> Can be changed using:
>
> $ ipa config-mod --defaultgroup ipausers
>
> You can probably do this in the UI as well but I'm a CLI guy.
>
> rob
>
>
> --_000_wr5vefergmq3fe5uuk63b7cn1496427649570emailandroidcom_
> Content-Type: text/html; charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> <html>
> <head>
> <meta http-equiv=3D"Content-Type" content=3D"text/html;
> charset=3Dus-ascii"=
> >
> </head>
> <body>
> <div>Look at automember rules.</div>
> <div><br>
> </div>
> <div><br>
> </div>
> <div><br>
> </div>
> <div id=3D"composer_signature">
> <div dir=3D"auto" style=3D"font-size:88%; color:#364f67">Verzonden vanaf
> mi=
> jn Samsung-apparaat</div>
> </div>
> <br>
> <br>
> -------- Oorspronkelijk bericht --------<br>
> Van: Devin Acosta via FreeIPA-users <freeipa-users@lists.
> fedorahosted.or=
> g> <br>
> Datum: 02-06-17 20:13 (GMT+01:00) <br>
> Aan: Rob Crittenden <rcritten(a)redhat.com> <br>
> Cc: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>,
> Devin =
> Acosta <linuxguru.co(a)gmail.com>
> <br>
> Onderwerp: [Freeipa-users] Re: FreeIPA (adding all new users to admin
> group=
> by default?)
> <br>
> <br>
> <div>
> <div dir=3D"ltr"><br>
> <div>Rob,</div>
> <div><br>
> </div>
> <div>That is what confuses me, I show that the default users group is
> "=
> ;ipausers", however when I added an account which I just tested it
> add=
> ed to admins group. Anything else that could be making it add it to
> t=
> he "admin" group?</div>
> <div><br>
> </div>
> <div>
> <div>[root@ipa01 ~]# ipa config-show</div>
> <div> Maximum username length: 32</div>
> <div> Home directory base: /home</div>
> <div> Default shell: /bin/bash</div>
> <div><b> Default users group: ipausers</b></div>
> <div> Default e-mail domain: m451.tech</div>
> <div> Search time limit: 2</div>
> <div> Search size limit: -1</div>
> <div> User search fields: uid,givenname,sn,
> telephonenumber,ou,title</=
> div>
> <div> Group search fields: cn,description</div>
> <div> Enable migration mode: FALSE</div>
> <div> Certificate Subject base: O=3DM451.TECH</div>
> <div> Password Expiration Notification (days): 4</div>
> <div> Password plugin features: AllowNThash</div>
> <div> SELinux user map order: guest_u:s0$xguest_u:s0$user_u:
> s0$staff_=
> u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023</div>
> <div> Default SELinux user: unconfined_u:s0-s0:c0.c1023</div>
> <div> Default PAC types: nfs:NONE, MS-PAC</div>
> </div>
> <div><br>
> </div>
> <div>
> <div>[root@ipa01 ~]# ipa user-add testuser-devin</div>
> <div>First name: Devin</div>
> <div>Last name: Acosta</div>
> <div>---------------------------</div>
> <div>Added user "testuser-devin"</div>
> <div>---------------------------</div>
> <div> User login: testuser-devin</div>
> <div> First name: Devin</div>
> <div> Last name: Acosta</div>
> <div> Full name: Devin Acosta</div>
> <div> Display name: Devin Acosta</div>
> <div> Initials: DA</div>
> <div> Home directory: /home/testuser-devin</div>
> <div> GECOS: Devin Acosta</div>
> <div> Login shell: /bin/bash</div>
> <div> Principal name: testuser-devin(a)M451.TECH</div>
> <div> Principal alias: testuser-devin(a)M451.TECH</div>
> <div> Email address: testuser-devin(a)m451.tech</div>
> <div> UID: 34375527</div>
> <div> GID: 34375527</div>
> <div> Password: False</div>
> <div> <b>Member of groups: ipausers, admins</b></div>
> <div> Roles: IT Security Specialist, sec_netops2, helpdesk, IT
> Specia=
> list, User Administrator, Security Architect, ipa_join</div>
> <div> Indirect Member of role: ipa_join, helpdesk, IT Security
> Specia=
> list, sec_netops2, IT Specialist, Security Architect, User
> Administrator</d=
> iv>
> <div> Kerberos keys available: False</div>
> </div>
> </div>
> <div class=3D"gmail_extra"><br>
> <div class=3D"gmail_quote">On Fri, Jun 2, 2017 at 11:02 AM, Rob Crittenden
> =
> <span dir=3D"ltr">
> <<a href=3D"mailto:rcritten@redhat.com" target=3D"_blank">rcritten@
> redha=
> t.com</a>></span> wrote:<br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;
> border-left:1=
> px #ccc solid; padding-left:1ex">
> <span class=3D"">Devin Acosta via FreeIPA-users wrote:<br>
> ><br>
> > I am hoping to see if someone can tell me what I either need to
> change=
> <br>
> > or update to get it so that FreeIPA doesn't automatically keep
> adding<=
> br>
> > all new users that is created automatically to the admin group. I<br>
> > inherited this installation of FreeIPA and so far haven't been able
> to=
> <br>
> > figure out what either got changed or how to disable this behavior? I
> =
> am<br>
> > running the latest FreeIPA 4.4 on CentOS 7.3.<br>
> ><br>
> > Any help would be greatly appreciated.<br>
> <br>
> </span>Probably the default users group. Try:<br>
> <br>
> $ kinit admin<br>
> $ ipa config-show |grep 'Default users group'<br>
> <br>
> Can be changed using:<br>
> <br>
> $ ipa config-mod --defaultgroup ipausers<br>
> <br>
> You can probably do this in the UI as well but I'm a CLI guy.<br>
> <span class=3D"HOEnZb"><font color=3D"#888888"><br>
> rob<br>
> </font></span></blockquote>
> </div>
> <br>
> </div>
> </div>
> </body>
> </html>
>
> --_000_wr5vefergmq3fe5uuk63b7cn1496427649570emailandroidcom_--
>
> ------------------------------
>
> Date: Fri, 2 Jun 2017 12:11:49 -0700
> From: Devin Acosta <linuxguru.co(a)gmail.com>
> Subject: [Freeipa-users] Re: FreeIPA (adding all new users to admin
> group by default?)
> To: wouter.hummelink(a)kpn.com
> Cc: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>, Rob
> Crittenden <rcritten(a)redhat.com>
> Message-ID:
> <CAAqg8eOxyAvPVT_AZQ17GbNx_JisCay6L2167NJwie499n81ww@
> mail.gmail.com>
> Content-Type: multipart/alternative;
> boundary="f40304354dd0e22ee50550feec46"
>
> --f40304354dd0e22ee50550feec46
> Content-Type: text/plain; charset="UTF-8"
>
> Thanks,
>
> That was the problem.
>
> [root@ipa01 ~]# ipa automember-default-group-show
> Grouping Type: group
> Default (fallback) Group: cn=admins,cn=groups,cn=
> accounts,dc=m451,dc=tech
> [root@ipa01 ~]
>
> Removed that and problem has been fixed.
>
> Thanks much!
>
> On Fri, Jun 2, 2017 at 11:20 AM, <wouter.hummelink(a)kpn.com> wrote:
>
> > Look at automember rules.
> >
> >
> >
> > Verzonden vanaf mijn Samsung-apparaat
> >
> >
> > -------- Oorspronkelijk bericht --------
> > Van: Devin Acosta via FreeIPA-users <freeipa-users@lists.
> fedorahosted.org>
> >
> > Datum: 02-06-17 20:13 (GMT+01:00)
> > Aan: Rob Crittenden <rcritten(a)redhat.com>
> > Cc: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>, Devin
> > Acosta <linuxguru.co(a)gmail.com>
> > Onderwerp: [Freeipa-users] Re: FreeIPA (adding all new users to admin
> > group by default?)
> >
> >
> > Rob,
> >
> > That is what confuses me, I show that the default users group is
> > "ipausers", however when I added an account which I just tested it added
> to
> > admins group. Anything else that could be making it add it to the
> "admin"
> > group?
> >
> > [root@ipa01 ~]# ipa config-show
> > Maximum username length: 32
> > Home directory base: /home
> > Default shell: /bin/bash
> > * Default users group: ipausers*
> > Default e-mail domain: m451.tech
> > Search time limit: 2
> > Search size limit: -1
> > User search fields: uid,givenname,sn,telephonenumber,ou,title
> > Group search fields: cn,description
> > Enable migration mode: FALSE
> > Certificate Subject base: O=M451.TECH
> > Password Expiration Notification (days): 4
> > Password plugin features: AllowNThash
> > SELinux user map order: guest_u:s0$xguest_u:s0$user_u:
> > s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
> > Default SELinux user: unconfined_u:s0-s0:c0.c1023
> > Default PAC types: nfs:NONE, MS-PAC
> >
> > [root@ipa01 ~]# ipa user-add testuser-devin
> > First name: Devin
> > Last name: Acosta
> > ---------------------------
> > Added user "testuser-devin"
> > ---------------------------
> > User login: testuser-devin
> > First name: Devin
> > Last name: Acosta
> > Full name: Devin Acosta
> > Display name: Devin Acosta
> > Initials: DA
> > Home directory: /home/testuser-devin
> > GECOS: Devin Acosta
> > Login shell: /bin/bash
> > Principal name: testuser-devin(a)M451.TECH
> > Principal alias: testuser-devin(a)M451.TECH
> > Email address: testuser-devin(a)m451.tech
> > UID: 34375527
> > GID: 34375527
> > Password: False
> > *Member of groups: ipausers, admins*
> > Roles: IT Security Specialist, sec_netops2, helpdesk, IT Specialist,
> > User Administrator, Security Architect, ipa_join
> > Indirect Member of role: ipa_join, helpdesk, IT Security Specialist,
> > sec_netops2, IT Specialist, Security Architect, User Administrator
> > Kerberos keys available: False
> >
> > On Fri, Jun 2, 2017 at 11:02 AM, Rob Crittenden <rcritten(a)redhat.com>
> > wrote:
> >
> >> Devin Acosta via FreeIPA-users wrote:
> >> >
> >> > I am hoping to see if someone can tell me what I either need to change
> >> > or update to get it so that FreeIPA doesn't automatically keep adding
> >> > all new users that is created automatically to the admin group. I
> >> > inherited this installation of FreeIPA and so far haven't been able to
> >> > figure out what either got changed or how to disable this behavior? I
> am
> >> > running the latest FreeIPA 4.4 on CentOS 7.3.
> >> >
> >> > Any help would be greatly appreciated.
> >>
> >> Probably the default users group. Try:
> >>
> >> $ kinit admin
> >> $ ipa config-show |grep 'Default users group'
> >>
> >> Can be changed using:
> >>
> >> $ ipa config-mod --defaultgroup ipausers
> >>
> >> You can probably do this in the UI as well but I'm a CLI guy.
> >>
> >> rob
> >>
> >
> >
>
> --f40304354dd0e22ee50550feec46
> Content-Type: text/html; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> <div dir=3D"ltr"><div><br></div><div>Thanks,</div><div><br></div><div>That
> =
> was the problem.</div><div><br></div><div><div>[root@ipa01 ~]# ipa
> automemb=
> er-default-group-show</div><div>Grouping Type: group</div><div>=C2=A0
> Defau=
> lt (fallback) Group: cn=3Dadmins,cn=3Dgroups,cn=
> 3Daccounts,dc=3Dm451,dc=3Dt=
> ech</div><div>[root@ipa01 ~]</div></div><div class=3D"gmail_extra"><br></
> di=
> v><div class=3D"gmail_extra">Removed that and problem has been
> fixed.</div>=
> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Thanks
> much=
> !</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri,
> Ju=
> n 2, 2017 at 11:20 AM, <span dir=3D"ltr"><<a href=3D"mailto:
> wouter.humm=
> elink(a)kpn.com" target=3D"_blank">wouter.hummelink(a)kpn.com</a>></span>
> wr=
> ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
> .8ex;border=
> -left:1px #ccc solid;padding-left:1ex">
>
>
>
> <div>
> <div>Look at automember rules.</div>
> <div><br>
> </div>
> <div><br>
> </div>
> <div><br>
> </div>
> <div id=3D"m_4874056557701448549composer_signature">
> <div dir=3D"auto" style=3D"font-size:88%;color:#364f67">Verzonden vanaf
> mij=
> n Samsung-apparaat</div>
> </div>
> <br>
> <br>
> -------- Oorspronkelijk bericht --------<br>
> Van: Devin Acosta via FreeIPA-users <<a href=3D"mailto:freeipa-users@
> lis=
> ts.fedorahosted.org" target=3D"_blank">freeipa-users@lists.
> <wbr>fedorahoste=
> d.org</a>> <br>
> Datum: 02-06-17 20:13 (GMT+01:00) <br>
> Aan: Rob Crittenden <<a href=3D"mailto:rcritten@redhat.com"
> target=3D"_b=
> lank">rcritten(a)redhat.com</a>> <br>
> Cc: FreeIPA users list <<a href=3D"mailto:freeipa-users@
> lists.fedorahost=
> ed.org" target=3D"_blank">freeipa-users@lists.<wbr>fedorahosted.org
> </a>>=
> , Devin Acosta <<a href=3D"mailto:linuxguru.co@gmail.com"
> target=3D"_bla=
> nk">linuxguru.co(a)gmail.com</a>>
> <br>
> Onderwerp: [Freeipa-users] Re: FreeIPA (adding all new users to admin
> group=
> by default?)
> <br><div><div class=3D"h5">
> <br>
> <div>
> <div dir=3D"ltr"><br>
> <div>Rob,</div>
> <div><br>
> </div>
> <div>That is what confuses me, I show that the default users group is
> "=
> ;ipausers", however when I added an account which I just tested it
> add=
> ed to admins group.=C2=A0 Anything else that could be making it add it to
> t=
> he "admin" group?</div>
> <div><br>
> </div>
> <div>
> <div>[root@ipa01 ~]# ipa config-show</div>
> <div>=C2=A0 Maximum username length: 32</div>
> <div>=C2=A0 Home directory base: /home</div>
> <div>=C2=A0 Default shell: /bin/bash</div>
> <div><b>=C2=A0 Default users group: ipausers</b></div>
> <div>=C2=A0 Default e-mail domain: m451.tech</div>
> <div>=C2=A0 Search time limit: 2</div>
> <div>=C2=A0 Search size limit: -1</div>
> <div>=C2=A0 User search fields: uid,givenname,sn,<wbr>
> telephonenumber,ou,ti=
> tle</div>
> <div>=C2=A0 Group search fields: cn,description</div>
> <div>=C2=A0 Enable migration mode: FALSE</div>
> <div>=C2=A0 Certificate Subject base: O=3DM451.TECH</div>
> <div>=C2=A0 Password Expiration Notification (days): 4</div>
> <div>=C2=A0 Password plugin features: AllowNThash</div>
> <div>=C2=A0 SELinux user map order: guest_u:s0$xguest_u:s0$user_u:
> <wbr>s0$s=
> taff_u:s0-s0:c0.c1023$<wbr>unconfined_u:s0-s0:c0.c1023</div>
> <div>=C2=A0 Default SELinux user: unconfined_u:s0-s0:c0.c1023</div>
> <div>=C2=A0 Default PAC types: nfs:NONE, MS-PAC</div>
> </div>
> <div><br>
> </div>
> <div>
> <div>[root@ipa01 ~]# ipa user-add testuser-devin</div>
> <div>First name: Devin</div>
> <div>Last name: Acosta</div>
> <div>---------------------------</div>
> <div>Added user "testuser-devin"</div>
> <div>---------------------------</div>
> <div>=C2=A0 User login: testuser-devin</div>
> <div>=C2=A0 First name: Devin</div>
> <div>=C2=A0 Last name: Acosta</div>
> <div>=C2=A0 Full name: Devin Acosta</div>
> <div>=C2=A0 Display name: Devin Acosta</div>
> <div>=C2=A0 Initials: DA</div>
> <div>=C2=A0 Home directory: /home/testuser-devin</div>
> <div>=C2=A0 GECOS: Devin Acosta</div>
> <div>=C2=A0 Login shell: /bin/bash</div>
> <div>=C2=A0 Principal name: testuser-devin(a)M451.TECH</div>
> <div>=C2=A0 Principal alias: testuser-devin(a)M451.TECH</div>
> <div>=C2=A0 Email address: testuser-devin(a)m451.tech</div>
> <div>=C2=A0 UID: 34375527</div>
> <div>=C2=A0 GID: 34375527</div>
> <div>=C2=A0 Password: False</div>
> <div>=C2=A0 <b>Member of groups: ipausers, admins</b></div>
> <div>=C2=A0 Roles: IT Security Specialist, sec_netops2, helpdesk, IT
> Specia=
> list, User Administrator, Security Architect, ipa_join</div>
> <div>=C2=A0 Indirect Member of role: ipa_join, helpdesk, IT Security
> Specia=
> list, sec_netops2, IT Specialist, Security Architect, User
> Administrator</d=
> iv>
> <div>=C2=A0 Kerberos keys available: False</div>
> </div>
> </div>
> <div class=3D"gmail_extra"><br>
> <div class=3D"gmail_quote">On Fri, Jun 2, 2017 at 11:02 AM, Rob Crittenden
> =
> <span dir=3D"ltr">
> <<a href=3D"mailto:rcritten@redhat.com" target=3D"_blank">rcritten@
> redha=
> t.com</a>></span> wrote:<br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
> .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex">
> <span>Devin Acosta via FreeIPA-users wrote:<br>
> ><br>
> > I am hoping to see if someone can tell me what I either need to
> change=
> <br>
> > or update to get it so that FreeIPA doesn't automatically keep
> add=
> ing<br>
> > all new users that is created automatically to the admin group. I<br>
> > inherited this installation of FreeIPA and so far haven't been
> abl=
> e to<br>
> > figure out what either got changed or how to disable this behavior? I
> =
> am<br>
> > running the latest FreeIPA 4.4 on CentOS 7.3.<br>
> ><br>
> > Any help would be greatly appreciated.<br>
> <br>
> </span>Probably the default users group. Try:<br>
> <br>
> $ kinit admin<br>
> $ ipa config-show |grep 'Default users group'<br>
> <br>
> Can be changed using:<br>
> <br>
> $ ipa config-mod --defaultgroup ipausers<br>
> <br>
> You can probably do this in the UI as well but I'm a CLI guy.<br>
> <span class=3D"m_4874056557701448549HOEnZb"><font color=3D"#888888"><br>
> rob<br>
> </font></span></blockquote>
> </div>
> <br>
> </div>
> </div>
> </div></div></div>
>
> </blockquote></div><br></div></div>
>
> --f40304354dd0e22ee50550feec46--
>
> ------------------------------
>
> Date: Fri, 2 Jun 2017 15:22:05 -0400
> From: Adrian HY <ayeja153(a)gmail.com>
> Subject: [Freeipa-users] export users to new freeipa server
> To: freeipa-users(a)lists.fedorahosted.org
> Message-ID:
> <CAOito+X7U2W7SNZ6Ga2z__rnRrc3gWLO=uJXdcPDpmdun369jQ@
> mail.gmail.com>
> Content-Type: multipart/alternative;
> boundary="94eb2c1cf3bc99d4320550ff1182"
>
> --94eb2c1cf3bc99d4320550ff1182
> Content-Type: text/plain; charset="UTF-8"
>
> Hi, I need to export an existing user from a freeipa server to another
> server, including password. Regards.
>
> --94eb2c1cf3bc99d4320550ff1182
> Content-Type: text/html; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> <div dir=3D"ltr">Hi, I need to export an existing user from a freeipa
> serve=
> r to another server, including password. Regards.=C2=A0</div>
>
> --94eb2c1cf3bc99d4320550ff1182--
>
> ------------------------------
>
> Date: Fri, 2 Jun 2017 15:27:01 -0400
> From: Striker Leggette <striker(a)terranforge.com>
> Subject: [Freeipa-users] Re: export users to new freeipa server
> To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
> Cc: Adrian HY <ayeja153(a)gmail.com>
> Message-ID: <9f513bc5-feae-c245-73b8-bafa003d1c79(a)terranforge.com>
> Content-Type: multipart/alternative;
> boundary="------------986A2380EEA4C56C02FC2CA9"
>
> This is a multi-part message in MIME format.
> --------------986A2380EEA4C56C02FC2CA9
> Content-Type: text/plain; charset=utf-8; format=flowed
> Content-Transfer-Encoding: 7bit
>
> We have documentation that might help:
>
> https://www.freeipa.org/page/V4/FreeIPA_to_FreeIPA_Migration
>
> Is this what you need?
>
>
> On 06/02/2017 03:22 PM, Adrian HY via FreeIPA-users wrote:
> > Hi, I need to export an existing user from a freeipa server to another
> > server, including password. Regards.
> >
> >
> > _______________________________________________
> > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> > To unsubscribe send an email to freeipa-users-leave@lists.
> fedorahosted.org
>
>
> --------------986A2380EEA4C56C02FC2CA9
> Content-Type: text/html; charset=utf-8
> Content-Transfer-Encoding: quoted-printable
>
> <html>
> <head>
> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf=
> -8">
> </head>
> <body text=3D"#000000" bgcolor=3D"#FFFFFF">
> <p><font size=3D"-1"><tt>We have documentation that might help:</tt><=
> /font></p>
> <p><font size=3D"-1"><tt><a class=3D"moz-txt-link-freetext" href=3D"h=
> ttps://www.freeipa.org/page/V4/FreeIPA_to_FreeIPA_Migration">https://www.=
> freeipa.org/page/V4/FreeIPA_to_FreeIPA_Migration</a></tt></font></p>
> <p><font size=3D"-1"><tt>Is this what you need?</tt></font><br>
> </p>
> <br>
> <div class=3D"moz-cite-prefix">On 06/02/2017 03:22 PM, Adrian HY via
> FreeIPA-users wrote:<br>
> </div>
> <blockquote type=3D"cite"
> cite=3D"mid:CAOito+X7U2W7SNZ6Ga2z__rnRrc3gWLO=3DuJXdcPDpmdun369jQ@mail.gm=
> ail.com">
> <div dir=3D"ltr">Hi, I need to export an existing user from a
> freeipa server to another server, including password. Regards.=C2=
> =A0</div>
> <br>
> <fieldset class=3D"mimeAttachmentHeader"></fieldset>
> <br>
> <pre wrap=3D"">_______________________________________________
> FreeIPA-users mailing list -- <a class=3D"moz-txt-link-abbreviated"
> href=3D=
> "mailto:freeipa-users@lists.fedorahosted.org">freeipa-users(a)lists.fedorah=
> osted.org</a>
> To unsubscribe send an email to <a class=3D"moz-txt-link-abbreviated" hre=
> f=3D"mailto:freeipa-users-leave@lists.fedorahosted.org">freeipa-users-lea=
> ve(a)lists.fedorahosted.org</a>
> </pre>
> </blockquote>
> <br>
> </body>
> </html>
>
> --------------986A2380EEA4C56C02FC2CA9--
>
> ------------------------------
>
> Date: Fri, 2 Jun 2017 14:05:34 -0600
> From: Frank Rey <frank.ray.reynoldsiii(a)gmail.com>
> Subject: [Freeipa-users] Scripting a SSSD client to add SID to
> UIDnumbers from ad Trust into custom LDAP schema.
> To: freeipa-users(a)lists.fedorahosted.org
> Message-ID:
> <CAHzNX24x5MiqoY4_VLrOQ3h8FpVjOb3ES_SB8ehxVEgecEMgTA(a)mail.gmail.
> com>
> Content-Type: multipart/alternative;
> boundary="001a113f022a1895390550ffad8d"
>
> --001a113f022a1895390550ffad8d
> Content-Type: text/plain; charset="UTF-8"
>
> I have a Netapp that does not support SSSD or Windbind and i want to use
> IDM ldap to do permission/name mapping. would using a Script on a SSSD
> client to populate a custom ldap schema in IPA with the SSSD uidnumber
> mappings be a bad idea? I know i would have to set up a cron job to run it
> at a reasonable interval. set it up to create and remove users added or
> removed from the Posix group i have mapped from the AD trust.
>
> Ray
>
> --001a113f022a1895390550ffad8d
> Content-Type: text/html; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> <div dir=3D"ltr"><div class=3D"gmail_quote"><br><div dir=3D"ltr"><div>I
> hav=
> e a Netapp that does not support SSSD or Windbind and i want to use IDM
> lda=
> p to do permission/name mapping. would using a Script on a SSSD client to
> p=
> opulate a custom ldap schema in IPA with the SSSD uidnumber mappings be a
> b=
> ad idea? I know i would have to set up a cron job to run it at a
> reasonable=
> interval. set it up to create and remove users added or removed from the
> P=
> osix group i have mapped from the AD trust. =C2=A0</div><br
> clear=3D"all"><=
> div><div class=3D"m_1675926449220289611gmail_signature"
> data-smartmail=3D"g=
> mail_signature"><div dir=3D"ltr"><div dir=3D"ltr">Ray<br><div><br></
> div></d=
> iv></div></div></div>
> </div>
> </div><br></div>
>
> --001a113f022a1895390550ffad8d--
>
> ------------------------------
>
> Date: Fri, 2 Jun 2017 20:52:54 -0400
> From: Brendan Kearney <bpk678(a)gmail.com>
> Subject: [Freeipa-users] Re: FreeIPA for simply managing DNS
> To: freeipa-users(a)lists.fedorahosted.org
> Message-ID: <baf1caf4-0291-8b1a-86b9-f87d011db019(a)gmail.com>
> Content-Type: multipart/alternative;
> boundary="------------403C6276125A532E124ED5A0"
>
> This is a multi-part message in MIME format.
> --------------403C6276125A532E124ED5A0
> Content-Type: text/plain; charset=utf-8; format=flowed
> Content-Transfer-Encoding: 7bit
>
> On 06/02/2017 01:10 PM, Striker Leggette via FreeIPA-users wrote:
> >
> > FreeIPA has a very well-made and easy to use DNS management GUI that
> > would serve well as a standalone tool. Are there any plans to fork
> > the DNS GUI like this for those who would like an easy DNS management
> > application who do not necessarily need LDAP/PKI/Kerberos/etc.?
> >
> > --
> > Striker Leggette
> > Identity Management
> >
> > linkedin.com/in/striker
> >
> >
> > _______________________________________________
> > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> > To unsubscribe send an email to freeipa-users-leave@lists.
> fedorahosted.org
>
> why not look at ISC BIND with bind-dyndb-ldap. i am using it, managing
> BIND zone data in my OpenLDAP directory.
>
>
> --------------403C6276125A532E124ED5A0
> Content-Type: text/html; charset=utf-8
> Content-Transfer-Encoding: quoted-printable
>
> <html>
> <head>
> <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty=
> pe">
> </head>
> <body bgcolor=3D"#FFFFFF" text=3D"#000000">
> <div class=3D"moz-cite-prefix">On 06/02/2017 01:10 PM, Striker
> Leggette via FreeIPA-users wrote:<br>
> </div>
> <blockquote
> cite=3D"mid:6f3803ff-6052-5f3a-3b57-b63d4b51f786@terranforge.com"
> type=3D"cite">
> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Du=
> tf-8">
> <p><tt><font size=3D"-1">FreeIPA has a very well-made and easy to
> use DNS management GUI that would serve well as a standalone
> tool.=C2=A0 Are there any plans to fork the DNS GUI like this=
> for
> those who would like an easy DNS management application who
> do not necessarily need LDAP/PKI/Kerberos/etc.?</font></tt><b=
> r>
> </p>
> <pre class=3D"moz-signature" cols=3D"72">--=20
> Striker Leggette
> Identity Management
>
> linkedin.com/in/striker</pre>
> <br>
> <fieldset class=3D"mimeAttachmentHeader"></fieldset>
> <br>
> <pre wrap=3D"">_______________________________________________
> FreeIPA-users mailing list -- <a class=3D"moz-txt-link-abbreviated"
> href=3D=
> "mailto:freeipa-users@lists.fedorahosted.org">freeipa-users(a)lists.fedorah=
> osted.org</a>
> To unsubscribe send an email to <a class=3D"moz-txt-link-abbreviated" hre=
> f=3D"mailto:freeipa-users-leave@lists.fedorahosted.org">freeipa-users-lea=
> ve(a)lists.fedorahosted.org</a>
> </pre>
> </blockquote>
> <p>why not look at ISC BIND with bind-dyndb-ldap.=C2=A0 i am using it=
> ,
> managing BIND zone data in my OpenLDAP directory.<br>
> </p>
> </body>
> </html>
>
> --------------403C6276125A532E124ED5A0--
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>
>
> ------------------------------
>
> End of FreeIPA-users Digest, Vol 2, Issue 2
> *******************************************
>
--
Chris Scutcher
E-Mail :: chris(a)scutcher.co.uk
Web :: http://chris.scutcher.co.uk
Phone:: +447743186526
6 years, 3 months
Re: certificate has expired?
by Rob Crittenden
Adding freeipa-users back.
Roberto Cornacchia wrote:
> Just to confirm, this is indeed the expired certificate
>
> $ getcert list -d /etc/httpd/alias -n Server-Cert
> Number of certificates and requests being tracked: 8.
> Request ID '20150316184529':
> status: CA_UNREACHABLE
> ca-error: Error setting up ccache for "host" service on client using
> default keytab: Cannot contact any KDC for requested realm.
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> certificate:
> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
> Certificate DB'
> CA: IPA
> issuer: CN=Certificate Authority,O=HQ.SPINQUE.COM <http://HQ.SPINQUE.COM>
> subject: CN=spinque04.hq.spinque.com
> <http://spinque04.hq.spinque.com>,O=HQ.SPINQUE.COM <http://HQ.SPINQUE.COM>
> expires: 2017-03-16 18:45:29 UTC
> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:
> post-save command: /usr/lib64/ipa/certmonger/restart_httpd
> track: yes
> auto-renew: yes
Since you have Apache up and limping along I'd first try:
# getcert resubmit -i 20150316184529
It is very possible that the tool will reject the server cert since it
is expired. If that happens then you'll need to set time back.
I'd encourage you to run: getcert list | grep expires
This will show you what certs need to be renewed and should give some
insight into the window of opportunity for setting the date back.
Assuming it's just the Apache cert that is expired I'd try setting the
date back to March 15, restart IPA, then I'd restart certmonger or try
the about resubmit command again.
Things can get tricky when some certs have renewed and some haven't.
rob
>
>
> On Wed, 7 Jun 2017 at 15:36 Roberto Cornacchia
> <roberto.cornacchia(a)gmail.com <mailto:roberto.cornacchia@gmail.com>> wrote:
>
> Thanks Rob,
>
> I've seen in similar posts that you recommend to go back in time and
> restart certmonger. Would it work in this case?
>
>
> On Wed, 7 Jun 2017 at 15:30 Rob Crittenden <rcritten(a)redhat.com
> <mailto:rcritten@redhat.com>> wrote:
>
> Roberto Cornacchia via FreeIPA-users wrote:
> > OK, I did so and httpd restarts.
> >
> > $ openssl s_client -connect 127.0.0.1:443
> <http://127.0.0.1:443> <http://127.0.0.1:443> -showcerts
> > CONNECTED(00000003)
> > depth=1 O = HQ.SPINQUE.COM <http://HQ.SPINQUE.COM>
> <http://HQ.SPINQUE.COM>, CN = Certificate
> > Authority
> > verify return:1
> > depth=0 O = HQ.SPINQUE.COM <http://HQ.SPINQUE.COM>
> <http://HQ.SPINQUE.COM>, CN =
> > spinque04.hq.spinque.com <http://spinque04.hq.spinque.com>
> <http://spinque04.hq.spinque.com>
> > verify error:num=10:certificate has expired
> > notAfter=Mar 16 18:45:29 2017 GMT
> > verify return:1
> > depth=0 O = HQ.SPINQUE.COM <http://HQ.SPINQUE.COM>
> <http://HQ.SPINQUE.COM>, CN =
> > spinque04.hq.spinque.com <http://spinque04.hq.spinque.com>
> <http://spinque04.hq.spinque.com>
> > notAfter=Mar 16 18:45:29 2017 GMT
> > verify return:1
> > ---
> > Certificate chain
> > 0 s:/O=HQ.SPINQUE.COM/CN=spinque04.hq.spinque.com
> <http://HQ.SPINQUE.COM/CN=spinque04.hq.spinque.com>
> > <http://HQ.SPINQUE.COM/CN=spinque04.hq.spinque.com>
> > i:/O=HQ.SPINQUE.COM/CN=Certificate
> <http://HQ.SPINQUE.COM/CN=Certificate>
> > <http://HQ.SPINQUE.COM/CN=Certificate> Authority
> > ...
> >
> > Fair enough, but why does this say it expires in 2019? Are
> they two
> > different certificates?
> >
> > $ getcert list -d /etc/httpd/alias -n ipaCert
> > Number of certificates and requests being tracked: 8.
> > Request ID '20160501114633':
> > status: MONITORING
> > stuck: no
> > key pair storage:
> >
> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
> > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> > certificate:
> >
> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
> > Certificate DB'
> > CA: dogtag-ipa-ca-renew-agent
> > issuer: CN=Certificate Authority,O=HQ.SPINQUE.COM
> <http://HQ.SPINQUE.COM> <http://HQ.SPINQUE.COM>
> > subject: CN=IPA RA,O=HQ.SPINQUE.COM <http://HQ.SPINQUE.COM>
> <http://HQ.SPINQUE.COM>
> > expires: 2019-01-26 19:41:51 UTC
> > key usage:
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> > eku: id-kp-serverAuth,id-kp-clientAuth
> > pre-save command: /usr/lib64/ipa/certmonger/renew_ra_cert_pre
> > post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert
> > track: yes
> > auto-renew: yes
> >
> > What's the right way to solve this?
>
> You're looking at the wrong cert.
>
> # getcert list -d /etc/httpd/alias -n Server-Cert
>
> And really, you should examine all certificate status, not just
> a single
> one.
>
> I was also strongly urge you to wait until all problems are resolved
> before attempting to update packages in the future (unless a package
> claims to fix a specific problem), particularly when it comes to
> certificates.
>
> rob
>
6 years, 3 months
Reminder: Southeast Linux Fest 2017
by Striker Leggette
Hi all,
This is a reminder of the upcoming Linux Fest this weekend (June 9th to
the 11th). We will have two folks manning a table for FreeIPA, showing
off features and spreading the good word while answering questions from
the audience.
If you're in the area, feel free to stop by.
3315 Scott Futrell Dr, Charlotte, NC 28208
--
Striker Leggette
Red Hat Identity Management
linkedin.com/in/striker
6 years, 3 months
Unable to communicate with CMS
by John Bowman
I'm hoping this is a firewall issue but I figured I would check just in
case I'm looking in the wrong direction.
I setup a pair non-CA replicas today and as far as I could tell everything
seemed to be okay but I noticed that when searching via the web ui on the
new replicas it would take 2 minutes to return information.
I the logs I noticed this time out error which is what I assumed was the
culprit:
[Wed Jun 07 14:48:31.155444 2017] [:error] [pid 14384] ipa: ERROR:
ra.find(): Unable to communicate with CMS ([Errno 110] Connection timed out)
I can see in tcpdump connections over ldap and 8080 which should be open
between the two and I wanted to verify if there should be any other ports
open that aren't covered in the install instructions or maybe something I
missed (7389 perhaps because its 4.x to 3.x communication).
Also I was hoping to cut down traffic across the network since the new
servers are in the EU and the old ones are in the US. Are there any
tips/instructions on doing something like this if its even possible?
# firewall-cmd --zone=public --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: ens224
sources:
services: dns http https kerberos kpasswd ldap ldaps ntp snmp ssh
Thanks!
--
John Bowman
6 years, 3 months