[Freeipa-users] Re: macOS-X bound to freeIPA - mkhomedir

[Alexander Bokovoy via FreeIPA-users]

On ke, 23 joulu 2020, Grant Janssen via FreeIPA-users wrote:

I’ve been running a number of macs bound to FreeIPA for years now.  The
biggest nuisance is that I haven’t found a way to make home directory
when one doesn’t exist.  Without a home directory, a users logs in, the
beachball spins forever and the user never gets a desktop because there
is no user home directory.

"createhomedir -c -a" functions (on most systems), but I’d rather not run this 
in cron.

Has anyone found the PAM secret to have this function like mkhomedir on
a CentOS host?

CentOS 7
grant@outhouse:~[20201213-6:51][#1003]$ authconfig --test | grep mkhome
pam_mkhomedir or pam_oddjob_mkhomedir is enabled (umask=0077)
grant@outhouse:~[20201213-6:51][#1004]$

I wish there were an authconfig on os-x


authconfig or authselect are only configuration tools. If there is no
underlying capability, it wouldn't help even if you have a configuration
tool as it wouldn't be able to configure anything.

I am not aware of any such tool for macOS.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Samba on IdM member failure

[Alexander Bokovoy via FreeIPA-users]

On ke, 23 joulu 2020, Alan Latteri via FreeIPA-users wrote:

Hello.

I have setup a test FreeIPA server and client, CentOS 8.3, very
minimal, exactly as the documentation.  I can successfully mount a
Samba shared from  ipaclient on MacOS, the first access. But any
subsequent share mounting fails until winbind is restarted.   Please
see this screen capture which explicitly shows the issue.

https://youtu.be/8Qd8u67WLkU

These errors appear in /var/log/messages:
Dec 23 13:31:15 ipaclient01 winbindd[1258]: [2020/12/23 13:31:15.265397,  0] 
../../source3/winbindd/winbindd_util.c:175(add_trusted_domain)
Dec 23 13:31:15 ipaclient01 winbindd[1258]:  add_trusted_domain: SID 
[S-1-5-21-1037681751-2390144637-354493272] already used by domain [IPA], 
expected [ipa.instinctual.studio]
Dec 23 13:31:15 ipaclient01 winbindd[1258]: [2020/12/23 13:31:15.265462,  0] 
../../source3/winbindd/winbindd_pam_auth_crap.c:169(winbindd_pam_auth_crap_done)
Dec 23 13:31:15 ipaclient01 winbindd[1258]:  winbindd_pam_auth_crap_done: 
add_trusted_domain_from_auth failed
Dec 23 13:31:17 ipaclient01 winbindd[1258]: [2020/12/23 13:31:17.263925,  0] 
../../source3/winbindd/winbindd_util.c:175(add_trusted_domain)
Dec 23 13:31:17 ipaclient01 winbindd[1258]:  add_trusted_domain: SID 
[S-1-5-21-1037681751-2390144637-354493272] already used by domain [IPA], 
expected [ipa.instinctual.studio]
Dec 23 13:31:17 ipaclient01 winbindd[1258]: [2020/12/23 13:31:17.263985,  0] 
../../source3/winbindd/winbindd_pam_auth_crap.c:169(winbindd_pam_auth_crap_done)
Dec 23 13:31:17 ipaclient01 winbindd[1258]:  winbindd_pam_auth_crap_done: 
add_trusted_domain_from_auth failed


Does it work for you with Kerberos authentication?

Either way, please create an issue at
https://pagure.io/freeipa/new_issue with all details, including full
samba logs.

Most of FreeIPA developers are on vacation for next week or two (I am
already and will only be back to work on Januarry 11th), so do not
expect prompt replies in this time. (This applies to most of threads on
the list).


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: LDAP client problem after upgrade to 4.8.7

[Avi White via FreeIPA-users]

I was able to replicate the issue on a test environment by installing 4.8.4 and
then upgrading it to 4.8.7.

Observations:

My base dn in nslcd.conf is set to dc=my,dc=org. It just worked and I never 
bothered how.
Turns out nslcd ends up working with the cn=compat tree. During login, it first
attempts to bind using myuser, and it worked in 4.8.4. nslcd debug logs:

nslcd: [8b4567]  DEBUG:
ldap_simple_bind_s("uid=myuser,cn=users,cn=compat,dc=my,dc=org","***")
(uri="ldap://ipa2.my.org;)
nslcd: [8b4567]  DEBUG: ldap_result():
uid=myuser,cn=users,cn=compat,dc=my,dc=org
nslcd: [8b4567]  DEBUG: ldap_unbind()
nslcd: [8b4567]  DEBUG: bind successful

It no longer works on FreeIPA 4.8.7:

nslcd: [b0dc51]  DEBUG: ldap_start_tls_s()
nslcd: [b0dc51]  DEBUG:
ldap_simple_bind_s("uid=myuser,cn=users,cn=compat,dc=my,dc=org","***")
(uri="ldap://ipa3.my.org;)
nslcd: [b0dc51]  ldap_result() failed: No such object
nslcd: [b0dc51] 
uid=myuser,cn=users,cn=compat,dc=my,dc=org: lookup failed: No such object
nslcd: [b0dc51]  DEBUG: ldap_unbind()

On my test instance, the output is slightly different for some reason, but to
the same effect:

nslcd: [495cff]  DEBUG: 
ldap_simple_bind_s("uid=myuser,cn=users,cn=compat,dc=ipa,dc=local","***") 
(uri="ldap://ipa1.ipa.local;)
nslcd: [495cff]  DEBUG: ldap_result(): end of results (0 total)
nslcd: [495cff]  uid=myuser,cn=users,cn=compat,dc=ipa,dc=local: 
lookup failed: No results returned


Why using the compat tree at all? What if I set the base dn to
cn=accounts,dc=my,dc=org? This works and user is able to login, but then nslcd
fails to obtain group membership. nslcd binds anonymously (by default) to
query LDAP to obtain group membership. This anonymous query works for the
cn=compat tree, but does not work for cn=accounts tree.

Workarounds:

Workaround 1 is to setup a dedicated user for LDAP queries and configure it in
nslcd.conf (binddn/bindpw), and set base to cn=accounts,dc=my,dc=org.

I did not want to do this, and setup a different base for group in nslcd.conf:

base cn=accounts,dc=my,dc=org
base group cn=compat,dc=my,dc=org

I'm still using cn=compat tree for group searches, but it allows nslcd to bind
anonymously to find group membership

I'm leaving this information here in case anyone faces the same issue.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Samba on IdM member failure

[Alan Latteri via FreeIPA-users]

Hello.

I have setup a test FreeIPA server and client, CentOS 8.3, very minimal, 
exactly as the documentation.  I can successfully mount a Samba shared from  
ipaclient on MacOS, the first access. But any subsequent share mounting fails 
until winbind is restarted.   Please see this screen capture which explicitly 
shows the issue.  

https://youtu.be/8Qd8u67WLkU

These errors appear in /var/log/messages:
Dec 23 13:31:15 ipaclient01 winbindd[1258]: [2020/12/23 13:31:15.265397,  0] 
../../source3/winbindd/winbindd_util.c:175(add_trusted_domain)
Dec 23 13:31:15 ipaclient01 winbindd[1258]:  add_trusted_domain: SID 
[S-1-5-21-1037681751-2390144637-354493272] already used by domain [IPA], 
expected [ipa.instinctual.studio]
Dec 23 13:31:15 ipaclient01 winbindd[1258]: [2020/12/23 13:31:15.265462,  0] 
../../source3/winbindd/winbindd_pam_auth_crap.c:169(winbindd_pam_auth_crap_done)
Dec 23 13:31:15 ipaclient01 winbindd[1258]:  winbindd_pam_auth_crap_done: 
add_trusted_domain_from_auth failed
Dec 23 13:31:17 ipaclient01 winbindd[1258]: [2020/12/23 13:31:17.263925,  0] 
../../source3/winbindd/winbindd_util.c:175(add_trusted_domain)
Dec 23 13:31:17 ipaclient01 winbindd[1258]:  add_trusted_domain: SID 
[S-1-5-21-1037681751-2390144637-354493272] already used by domain [IPA], 
expected [ipa.instinctual.studio]
Dec 23 13:31:17 ipaclient01 winbindd[1258]: [2020/12/23 13:31:17.263985,  0] 
../../source3/winbindd/winbindd_pam_auth_crap.c:169(winbindd_pam_auth_crap_done)
Dec 23 13:31:17 ipaclient01 winbindd[1258]:  winbindd_pam_auth_crap_done: 
add_trusted_domain_from_auth failed

Below are the exact server and client install steps:



FreeIPA Server Setup


[root@freeipa01 ~]# more /etc/redhat-release 
CentOS Linux release 8.3.2011

[root@freeipa01 ~]# uname -a
Linux freeipa01.ipa.instinctual.studio 4.18.0-240.1.1.el8_3.x86_64 #1 SMP Thu 
Nov 19 17:20:08 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

[root@freeipa01 ~]# systemctl disable --now firewalld
[root@freeipa01 ~]# dnf module install -y idm:DL1/{server,client,dns,adtrust}
[root@freeipa01 ~]# ipa-server-install --setup-dns --auto-reverse

The log file for this installation can be found in 
/var/log/ipaserver-install.log
==
This program will set up the IPA Server.
Version 4.8.7

This includes:
  * Configure a stand-alone CA (dogtag) for certificate management
  * Configure the NTP client (chronyd)
  * Create and configure an instance of Directory Server
  * Create and configure a Kerberos Key Distribution Center (KDC)
  * Configure Apache (httpd)
  * Configure DNS (bind)
  * Configure the KDC to enable PKINIT

To accept the default shown in brackets, press the Enter key.


Enter the fully qualified domain name of the computer
on which you're setting up server software. Using the form
.
Example: master.example.com.


Server host name [freeipa01.ipa.instinctual.studio]: 

Warning: skipping DNS resolution of host freeipa01.ipa.instinctual.studio
The domain name has been determined based on the host name.

Please confirm the domain name [ipa.instinctual.studio]: 

The kerberos protocol requires a Realm name to be defined.
This is typically the domain name converted to uppercase.

Please provide a realm name [IPA.INSTINCTUAL.STUDIO]: 
Certain directory server operations require an administrative user.
This user is referred to as the Directory Manager and has full access
to the Directory for system management tasks and will be added to the
instance of directory server created for IPA.
The password must be at least 8 characters long.

Directory Manager password: 
Password (confirm): 

The IPA server requires an administrative user, named 'admin'.
This user is a regular system account used for IPA server administration.

IPA admin password: 
Password (confirm): 

Checking DNS domain ipa.instinctual.studio., please wait ...
DNS check for domain ipa.instinctual.studio. failed: All nameservers failed to 
answer the query ipa.instinctual.studio. IN SOA: Server 8.8.8.8 UDP port 53 
answered SERVFAIL; Server 9.9.9.9 UDP port 53 answered SERVFAIL.
Invalid IP address fe80::5005:3a7d:8c39:957c for 
freeipa01.ipa.instinctual.studio: cannot use link-local IP address 
fe80::5005:3a7d:8c39:957c
Do you want to configure DNS forwarders? [yes]: 
Following DNS servers are configured in /etc/resolv.conf: 8.8.8.8, 9.9.9.9
Do you want to configure these servers as DNS forwarders? [yes]: 
All DNS servers from /etc/resolv.conf were added. You can enter additional 
addresses now:
Enter an IP address for a DNS forwarder, or press Enter to skip: 
Checking DNS forwarders, please wait ...
Checking DNS domain 200.0.10.in-addr.arpa., please wait ...
Reverse zone 200.0.10.in-addr.arpa. will be created
Using reverse zone(s) 200.0.10.in-addr.arpa.
Do you want to configure chrony with NTP server or pool address? [no]: 

The IPA Master Server will be configured with:
Hostname:   

[Freeipa-users] Re: FreeIPA with containers

[Larkin, Patrick via FreeIPA-users]

Kevin, I cannot speak to your specific use case, but regarding this:
On 12/23/2020 9:50 AM, Kevin Vasko via FreeIPA-users wrote:


 could enrolling 100s or 1000s of containers cause an issue for 
freeIPA?Most of these would be fairly short lived (few days to weeks). 
At that point I would need to go manually cleanup all of the enrolled 
machines.



This could be a problem depending on how large your FreeIPA replication 
farm is, and whether you have safeguards to keep the enrollments under 
control.   For example we had a user with an auto-scaling group which 
was supposed to spin up 100 or so instances.   A flaw in their code 
caused the instances to die quickly, which the auto-scaling group would 
try to replace.    Left alone, we ended up with 50,000 unused host 
entries in ipa.   As it was happening, these new entries had to 
replicate across our very large ipa farm causing slow performance & 
service interruptions far far away from the faulty auto-scaling group.


--
Pat Larkin  | Texas USA  |

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: healthcheck errors

[Prasun Gera via FreeIPA-users]

Thanks. That has fixed a part of the problem. I did the rename followed by
ipa-certupdate, which clears the duplicate nickname. It also shows only a
single value under the nickname now. I don't see the CS.cfg error anymore.
However, something is still not right with certupdate and tracking. After
certupdate, I get the tracking error in healthcheck. If I do
ipa-server-upgrade, it fixes the tracking and also prints this:
"Missing or incorrect tracking request for certificates:
  /etc/pki/pki-tomcat/alias:caSigningCert cert-pki-ca"
after which healthcheck reports no errors. Running certupdate brings the
error back.

On Wed, Dec 23, 2020 at 10:04 AM Rob Crittenden  wrote:

> Prasun Gera via FreeIPA-users wrote:
> > Renaming creates a duplicate. There was already a 'caSigningCert
> > cert-pki-ca' present in the db. Now it shows two entries with the same
> > nick. This shouldn't happen, right ? Should I delete 'DOMAIN.COM
> >  IPA CA' instead (after restoring
> > /etc/pki/pki-tomcat/alias/)? It had the same contents as 'caSigningCert
> > cert-pki-ca'. Here is what it looks like:
> >
> > certutil -L -d /etc/pki/pki-tomcat/alias/
> >
> > Certificate Nickname Trust
> > Attributes
> >
> >  SSL,S/MIME,JAR/XPI
> >
> > Server-Cert cert-pki-ca  u,u,u
> > subsystemCert cert-pki-cau,u,u
> > auditSigningCert cert-pki-ca u,u,Pu
> > ocspSigningCert cert-pki-ca  u,u,u
> > caSigningCert cert-pki-caCTu,Cu,Cu
> > caSigningCert cert-pki-caCTu,Cu,Cu
>
> I think that ipa-certupdate was adding the other nickname. I believe
> this will prevent that.
>
> rob
>
> >
> > On Tue, Dec 22, 2020 at 10:22 AM Rob Crittenden  > > wrote:
> >
> > Prasun Gera wrote:
> > > Thanks, Rob. Here are the outputs:
> > >
> > > certutil -L -d /etc/pki/pki-tomcat/alias/
> > >
> > > Certificate Nickname Trust
> > > Attributes
> > >
> > >  SSL,S/MIME,JAR/XPI
> > >
> > > Server-Cert cert-pki-ca  u,u,u
> > > subsystemCert cert-pki-cau,u,u
> > > auditSigningCert cert-pki-ca u,u,Pu
> > > ocspSigningCert cert-pki-ca  u,u,u
> > > caSigningCert cert-pki-ca
>  CTu,Cu,Cu
> > > DOMAIN.COM   IPA CA
> >
> > >  CTu,Cu,Cu
> >
> > That identifies one problem. The nickname that is currently
> > 'DOMAIN.COM 
> > IPA CA' should be 'caSigningCert cert-pki-ca'.
> >
> > To fix:
> >
> > 1. ipa cert-show 1 (output doesn't matter just shouldn't be an error)
> > 2. ipactl stop
> > 3. backup /etc/pki/pki-tomcat/alias/* someplace safe
> > 4. certutil --rename -d /etc/pki/pki-tomcat/alias/ --new-n
> > 'caSigningCert cert-pki-ca' -n 'DOMAIN.COM  IPA
> CA'
> > 5. ipactl start
> > 6. ipa cert-show 1 (again, should return a cert)
> >
> > > getcert list -d /etc/pki/pki-tomcat/alias/ -n 'caSigningCert
> > cert-pki-ca'
> > > Number of certificates and requests being tracked: 9.
> > > Request ID '20201221144720':
> > > status: MONITORING
> > > stuck: no
> > > key pair storage:
> > >
> >
>  type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
> > > cert-pki-ca',token='NSS Certificate DB',pin set
> > > certificate:
> > >
> >
>  type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
> > > cert-pki-ca',token='NSS Certificate DB'
> > > CA: dogtag-ipa-ca-renew-agent
> > > issuer: CN=Certificate Authority,O=DOMAIN.COM 
> > 
> > > subject: CN=Certificate Authority,O=DOMAIN.COM 
> > 
> > > expires: 2040-12-21 06:51:45 EST
> > > key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
> > > profile: caCACert
> > > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
> > > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
> > > "caSigningCert cert-pki-ca"
> > > track: yes
> > > auto-renew: yes
> > >
> > > The other thing I tried was ipa-server-upgrade, which does resolve
> the
> > > 2nd failure. It adds the missing tracking. However, if I run
> > > ipa-certupdate after that, the error appears again. It appears that
> > > ipa-certupdate clears it. One thing worth mentioning is that I had
> > > run ipa-cacert-manage renew earlier. Is this related to it somehow
> > ? I'm
> > > not entirely sure why there are two certificates with two serial
> > > numbers. They both have the same validity 

[Freeipa-users] macOS-X bound to freeIPA - mkhomedir

[Grant Janssen via FreeIPA-users]

I’ve been running a number of macs bound to FreeIPA for years now.  The biggest 
nuisance is that I haven’t found a way to make home directory when one doesn’t 
exist.
Without a home directory, a users logs in, the beachball spins forever and the 
user never gets a desktop because there is no user home directory.

"createhomedir -c -a" functions (on most systems), but I’d rather not run this 
in cron.

Has anyone found the PAM secret to have this function like mkhomedir on a 
CentOS host?

CentOS 7
grant@outhouse:~[20201213-6:51][#1003]$ authconfig --test | grep mkhome
pam_mkhomedir or pam_oddjob_mkhomedir is enabled (umask=0077)
grant@outhouse:~[20201213-6:51][#1004]$

I wish there were an authconfig on os-x

- grant
This e-mail and any attachments are intended only for use by the addressee(s) 
named herein and may contain confidential information. If you are not the 
intended recipient of this e-mail, you are hereby notified any dissemination, 
distribution or copying of this email and any attachments is strictly 
prohibited. If you receive this email in error, please immediately notify the 
sender by return email and permanently delete the original, any copy and any 
printout thereof. The integrity and security of e-mail cannot be guaranteed.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] FreeIPA with containers

[Kevin Vasko via FreeIPA-users]

Hello,
 
We have our NFS servers kerberized which requires a ticket to be able to access 
the NFS share. We also have a GPU cluster where people get to launch docker 
containers to complete work. Unfortunately, within the container users can’t 
access the NFS share even though its mapped on the host machine and in the 
container because they don’t have a ticket within the container.
 
So what are my options to deal with this? Would building a container and when 
it starts up, automatically enroll itself into FreeIPA be the best solution? As 
a test I tried to enroll the container in one of our test containers and 
freeipa-client-install complained that pid 1 wasn’t being ran by systemd, not 
quite sure how to get around that. However even if this was accomplished could 
enrolling 100s or 1000s of containers cause an issue for freeIPA?Most of these 
would be fairly short lived (few days to weeks). At that point I would need to 
go manually cleanup all of the enrolled machines.
 
The other and less optimal solution would be to use a non kerberized NFS share, 
pass through the uid/gid from the host, but with this solution users would know 
their own UID/GID in the container but wouldn’t know who owns what in the 
container because they would have nothing tell them in the container what 
UID/GID is associated with what account so it might get confusing.
 
I’m really just looking for any suggestions on what other people have done. I’m 
not even sure if what I’m doing is the right approach at all and I should be 
doing something totally different. Are there any other solutions/suggestions 
that people have used to operate with FreeIPA along with docker containers?

-Kevin___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: "missing attribute sn" error on migration

[Jacquelin Charbonnel via FreeIPA-users]

I don't know  the goal of the compat mode. But with accounts in place of 
compat, it's works !


Thank you, and happy new year !
Jacquelin

Le 23/12/2020 à 16:07, Rob Crittenden a écrit :

Jacquelin Charbonnel via FreeIPA-users wrote:

Hi everyone,

 To create a nice new proper domain in CentOS8 (with a new name and
so), I use "ipa migrate-ds" on a fresh installed Centos8 server, to
retrieve entries from my current domain in CentOS7 :

ipa migrate-ds ldap://my_current_server:389
--user-container=cn=users,cn=compat,dc=ipa,dc=math
--bind-dn="cn=Directory Manager" --user-objectclass=posixAccount
--group-container=cn=groups,cn=compat,dc=ipa,dc=math
--group-objectclass=posixGroup

 But "ipa migrate-ds" fails with this message for each user :

   xxx: missing attribute "sn" required by object class
"organizationalPerson"

with a final :

No users/groups were migrated from ldap://...:389

 I try with and without --with-compat option, and with
ipa-compat-manage enabled and disabled.

 But when I look at ldap entries on the server in production, I see
however a sn record (containing the last name) for each user. So where
is the bug ?


I don't believe this is related but why are you using the compat
containers for users and groups? I'd suggest s/cn=compat/cn=accounts/.

rob



--
Jacquelin Charbonnel - (+33)2 4173 5397
CNRS Mathrice/LAREMA - Campus universitaire d'Angers
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: "missing attribute sn" error on migration

[Jacquelin Charbonnel via FreeIPA-users]

Fine, it's works !!

Thank you, and merry Christmas
Jacquelin

Le 23/12/2020 à 14:19, Florence Blanc-Renaud via FreeIPA-users a écrit :
Can you retry with --user-container=cn=users,cn=accounts,dc=ipa,dc=math 
and --group-container=cn=groups,cn=accounts,dc=ipa,dc=math?


--
Jacquelin Charbonnel - (+33)2 4173 5397
CNRS Mathrice/LAREMA - Campus universitaire d'Angers
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: "missing attribute sn" error on migration

[Rob Crittenden via FreeIPA-users]

Jacquelin Charbonnel via FreeIPA-users wrote:
> Hi everyone,
> 
> To create a nice new proper domain in CentOS8 (with a new name and
> so), I use "ipa migrate-ds" on a fresh installed Centos8 server, to
> retrieve entries from my current domain in CentOS7 :
> 
> ipa migrate-ds ldap://my_current_server:389
> --user-container=cn=users,cn=compat,dc=ipa,dc=math
> --bind-dn="cn=Directory Manager" --user-objectclass=posixAccount
> --group-container=cn=groups,cn=compat,dc=ipa,dc=math
> --group-objectclass=posixGroup
> 
> But "ipa migrate-ds" fails with this message for each user :
> 
>   xxx: missing attribute "sn" required by object class
> "organizationalPerson"
> 
> with a final :
> 
> No users/groups were migrated from ldap://...:389
> 
> I try with and without --with-compat option, and with
> ipa-compat-manage enabled and disabled.
> 
> But when I look at ldap entries on the server in production, I see
> however a sn record (containing the last name) for each user. So where
> is the bug ?

I don't believe this is related but why are you using the compat
containers for users and groups? I'd suggest s/cn=compat/cn=accounts/.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] FreeIPA 4.9.0 released

[Alexander Bokovoy via FreeIPA-users]

Hello,

The FreeIPA team would like to announce FreeIPA 4.9.0 release!

It can be downloaded from http://www.freeipa.org/page/Downloads. Builds
for Fedora distributions will be available from the official repository
soon.

Due to the large size of the updates, please see all the details at
https://www.freeipa.org/page/Releases/4.9.0. Many of the updates were
already seen in FreeIPA 4.8 releases as they were backported there.
Nevertheless, the full list of changes can be found at the page linked
above.

== Highlights in 4.9.0

* 298: [RFE] Add support for cracklib to password policies

FreeIPA password quality checking plugin has been extended to use
libpwquality library. Password policies can now check for a reuse of
a user name, dictionary words using a cracklib package, numbers and
symbols replacement and repeating characters in the passwords.

* 2445: [RFE] IdM password policy should include checks for repeating
characters

FreeIPA password quality checking plugin has been extended to use
libpwquality library. Password policies can now check for a reuse of
a user name, dictionary words using a cracklib package, numbers and
symbols replacement and repeating characters in the passwords.

* 3299: [RFE] Switch the client to JSON RPC

Clients now communicate with FreeIPA server via JSON-RPC instead of
XML-RPC by default. The new interface for example allows sending
additional information (notices, warnings) when a management
operation ends with an error.

* 3687: [RFE] IPA user account expiry warning.

EPN stands for Expiring Password Notification. It is a standalone
tool designed to build a list of users whose password would expire
in the near future, and either display the list in a
machine-readable (JSON) format, or send email notifications to these
users. EPN provides command-line options to display the list of
affected users. This provides data introspection and helps
understand how many emails would be sent for a given day, or a given
date range. The command-line options can also be used by a
monitoring system to alert whenever a number of emails over the SMTP
quota would be sent. EPN is meant to be launched once a day from an
IPA client (preferred) or replica from a systemd timer. EPN does not
keep state: the list of affected users is built at runtime but never
kept.

* 3827: [RFE] Expose TTL in web UI

DNS record time to live (TTL) parameters can be edited in Web UI

* 3999: [RFE] Fix and Document how to set up Samba File Server with IPA

Samba file server can now be configured on the FreeIPA-enrolled
system to provide file services to users in IPA domain and to users
from trusted Active Directory forests

* 4751: Implement ACME certificate enrolment

Configure the Automatic Certificate Management Environment (ACME)
protocol support provided by the dogtag CA.

* 5011: [RFE] Forward CA requests to dogtag or helper by GSSAPI

* 5608: [RFE] Add Dogtag configuration extensions

* 5662: ID Views: do not allow custom Views for the masters

Custom ID views cannot be applied to IPA masters. A check was added
to both IPA CLI and Web UI to prevent applying custom ID views to
avoid confusion and unintended side-effects.

* 5948: [RFE] Implement pam_pwquality featureset in IPA password
policies

* 6783: [RFE] Host-group names command rename

host groups can now be renamed with IPA CLI: 'ipa hostgroup-mod
group-name --rename new-name'. Protected hostgroups ('ipaservers')
cannot be renamed.

* 7137: [RFE]: Able to browse different links from IPA web gui in new
tabs

* 7181: ipa-replica-prepare fails for 2nd replica when passwordHistory
is enabled

FreeIPA password policy plugin in 389-ds was extended to exempt
non-Kerberos LDAP objects from checking Kerberos policy during
password changes by the Directory Manager or a password
synchronization manager. This issue affected, among others, an
integrated CA administrator account during deployment of more than
one replica in some cases.

* 7522: Disable cert publishing in dogtag

Dogtag certificate publishing facility is not configured anymore as
it is not used in FreeIPA.

* 7577: [RFE] DNS package check should be called earlier in installation
routine

The ``--setup-dns`` knob and interactive installer now both check
for the presence of freeipa-server-dns early and abort the installer
with an error before starting actual deployment.

* 7695: ipa service-del should display principal name instead of Invalid
'principal'.

When deleting services, report exact name of a system required
principal that couldn't be deleted.

* 7966: Add support for JSON-RPC in ipa-join

ipa-join tool defaults to use of JSON-RPC protocol when
communicating to IPA masters by default. The choice of JSON-RPC or
XML-RPC is a compile-time setting now.

* 7971: [RFE] Include hint for 

[Freeipa-users] Re: repair ca

[Thorsten Scherf via FreeIPA-users]

ldapsearch -D "cn=directory manager" -W -b o=ipaca "(uid=ipara)"
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (uid=ipara)
# requesting: ALL
#

# ipara, people, ipaca
dn: uid=ipara,ou=people,o=ipaca
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: cmsuser
uid: ipara
sn: ipara
cn: ipara
usertype: agentType
userstate: 1
userCertificate:: MIID4TCCAkmgAwIBAgIBBzANBgkqhkiG9w0BAQsFADA2MRQwEgYDVQQKDAtM
T0MuRVBITC5CWTEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTIwMDYzMDE5MzE1M
VoXDTIyMDYyMDE5MzE1MVowJzEUMBIGA1UECgwLTE9DLkVQSEwuQlkxDzANBgNVBAMTBklQQSBSQT
CCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALieCvFxG8rA+dpk3G2cXsaRAepgSYRwQy0
iXnzQm+c00ANABfCYdRog3XF2TXZzpUnEjG4BA0XGId/GV/jhROrMz3TMCYZASVlX1ucd3SrGpkNY
RqVMwQir8b8hdyzhO0BA4k2z+AIyJk2LP0RdHYb1I34e5D5ys1O9Hyi+VhBK1lfmLEyTB56nwp2wt
Y0PnK2OnQPQjKhS+FmDAciI3jOf0wUR0z+NY37JcX5HwaqHkVeitMS/rJoRBdXWU4f68cgHw5J6JP
3wB2HPLMRRLkXeRRdz1yrYAdNIfNEHsSEVrwjM8K76bu+aZ9Cdz8dlB4cVX4+44RR36pB/OVjcfh0
CAwEAAaOBiDCBhTAfBgNVHSMEGDAWgBRAqsIyAvQfYf69qbdaPaXhdXQT4jA9BggrBgEFBQcBAQQx
MC8wLQYIKwYBBQUHMAGGIWh0dHA6Ly9pcGEtY2EubG9jLmVwaGwuYnkvY2Evb2NzcDAOBgNVHQ8BA
f8EBAMCBLAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQELBQADggGBADiqrIuv4IqJ3C
Q0D4W9IT9irKPsuKMonbWBwZ53vF3FRLYNvg/WNghzLkHhIKLQ4/crJpqSjAvRtBj7tKY9weOJ7XJ
VWr/nC4SaShLGB8CCOVPfZ+AcOHRsNXODzixsni0RPPFgYzeuBb5VYOybqHsxWs6bAJ1dzWtSH7pb
TdicgdteVa+F/LPeHnstMRAuYldW8+/1f0eyzCI3InNk4jWp+AhfEkcxYGVuF/77/hVnpNK9wx+MN
OM9Rbb7v0a0IDcBqp/8jNzKOzXabwYYkc/58yIqPTntArGBb9+InRBDSzMAB6ggjtd4dmiKII5Cb4
gnjYZzVzVM3NwE8WjZcWu/pY3Ea3oiMYLvgQupIjOePVcEBkm5ASwSS3eC/OP2ofO139h7PjsGl/z
Qa0981ESnqlc+IxvqtB0ELnid2ryNg0VmugTZWf+TpCH44N3cl4gdfSickOcoX3Hv3FfFe98BNo/o
VmqTFOmllduUMjn8HJfLbpvLiIpbatoYvAvoBA==
description: 2;7;CN=Certificate Authority,O=DOMAIN.COM;CN=IPA RA,O=LOC.EPHL.B
Y

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

openssl x509 -text -in /var/lib/ipa/ra-agent.pem
Certificate:
   Data:
   Version: 3 (0x2)
   Serial Number: 7 (0x7)
   Signature Algorithm: sha256WithRSAEncryption
   Issuer: O = DOMAIN.COM, CN = Certificate Authority
   Validity
   Not Before: Jun 30 19:31:51 2020 GMT
   Not After : Jun 20 19:31:51 2022 GMT
   Subject: O = DOMAIN.COM, CN = IPA RA
   Subject Public Key Info:
   Public Key Algorithm: rsaEncryption
   RSA Public-Key: (2048 bit)
   Modulus:
   00:b8:9e:0a:f1:71:1b:ca:c0:f9:da:64:dc:6d:9c:
   5e:c6:91:01:ea:60:49:84:70:43:2d:22:5e:7c:d0:
   9b:e7:34:d0:03:40:05:f0:98:75:1a:20:dd:71:76:
   4d:76:73:a5:49:c4:8c:6e:01:03:45:c6:21:df:c6:
   57:f8:e1:44:ea:cc:cf:74:cc:09:86:40:49:59:57:
   d6:e7:1d:dd:2a:c6:a6:43:58:46:a5:4c:c1:08:ab:
   f1:bf:21:77:2c:e1:3b:40:40:e2:4d:b3:f8:02:32:
   26:4d:8b:3f:44:5d:1d:86:f5:23:7e:1e:e4:3e:72:
   b3:53:bd:1f:28:be:56:10:4a:d6:57:e6:2c:4c:93:
   07:9e:a7:c2:9d:b0:b5:8d:0f:9c:ad:8e:9d:03:d0:
   8c:a8:52:f8:59:83:01:c8:88:de:33:9f:d3:05:11:
   d3:3f:8d:63:7e:c9:71:7e:47:c1:aa:87:91:57:a2:
   b4:c4:bf:ac:9a:11:05:d5:d6:53:87:fa:f1:c8:07:
   c3:92:7a:24:fd:f0:07:61:cf:2c:c4:51:2e:45:de:
   45:17:73:d7:2a:d8:01:d3:48:7c:d1:07:b1:21:15:
   af:08:cc:f0:ae:fa:6e:ef:9a:67:d0:9d:cf:c7:65:
   07:87:15:5f:8f:b8:e1:14:77:ea:90:7f:39:58:dc:
   7e:1d
   Exponent: 65537 (0x10001)
   X509v3 extensions:
   X509v3 Authority Key Identifier:
   keyid:40:AA:C2:32:02:F4:1F:61:FE:BD:A9:B7:5A:3D:A5:E1:75:74:13:E2

   Authority Information Access:
   OCSP - URI:http://ipa-ca.domain.com/ca/ocsp

   X509v3 Key Usage: critical
   Digital Signature, Key Encipherment, Data Encipherment
   X509v3 Extended Key Usage:
   TLS Web Client Authentication
   Signature Algorithm: sha256WithRSAEncryption
38:aa:ac:8b:af:e0:8a:89:dc:24:34:0f:85:bd:21:3f:62:ac:
a3:ec:b8:a3:28:9d:b5:81:c1:9e:77:bc:5d:c5:44:b6:0d:be:
0f:d6:36:08:73:2e:41:e1:20:a2:d0:e3:f7:2b:26:9a:92:8c:
0b:d1:b4:18:fb:b4:a6:3d:c1:e3:89:ed:72:55:5a:bf:e7:0b:
84:9a:4a:12:c6:07:c0:82:39:53:df:67:e0:1c:38:74:6c:35:
73:83:ce:2c:6c:9e:2d:11:3c:f1:60:63:37:ae:05:be:55:60:
ec:9b:a8:7b:31:5a:ce:9b:00:9d:5d:cd:6b:52:1f:ba:5b:4d:
d8:9c:81:db:5e:55:af:85:fc:b3:de:1e:7b:2d:31:10:2e:62:
57:56:f3:ef:f5:7f:47:b2:cc:22:37:22:73:64:e2:35:a9:f8:
08:5f:12:47:31:60:65:6e:17:fe:fb:fe:15:67:a4:d2:bd:c3:
1f:8c:34:e3:3d:45:b6:fb:bf:46:b4:20:37:01:aa:9f:fc:8c:
dc:ca:3b:35:da:6f:06:18:91:cf:f9:f3:22:2a:3d:39:ed:02:
b1:81:6f:df:88:9d:10:43:4b:33:00:07:a8:20:8e:d7:78:76:

[Freeipa-users] Re: addition of a user with given UID - Samba does not see the user.

[Alexander Bokovoy via FreeIPA-users]

On ti, 22 joulu 2020, lejeczek via FreeIPA-users wrote:


Hi guys,

IPA with Samba integrated and users migrated from another IPA and a 
user was available to Samba.

Then on a second master too
-> $ ipa-adtrust-install
was run and I think that was the only bit done. Then user was removed 
and added with the same UID and Samba does not see that user, which 
user elsewhere works fine.
Removal was done with --no-preserve and also without it but no 
difference.


Any suggestions as how to fix it are greatly appreciated.


Start with the user's LDAP entry. Check that ipaNTSecurityIdentifier
attribute exists and has SID in the same domain as IPA SID (visible in
'ipa trustconfig-show').

After that, collect Samba logs with 'log level = 10' when attempting to
connect as this user. 



--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: "missing attribute sn" error on migration

[Florence Blanc-Renaud via FreeIPA-users]

On 12/23/20 10:19 AM, Jacquelin Charbonnel via FreeIPA-users wrote:

Hi everyone,

 To create a nice new proper domain in CentOS8 (with a new name and 
so), I use "ipa migrate-ds" on a fresh installed Centos8 server, to 
retrieve entries from my current domain in CentOS7 :


ipa migrate-ds ldap://my_current_server:389 
--user-container=cn=users,cn=compat,dc=ipa,dc=math 
--bind-dn="cn=Directory Manager" --user-objectclass=posixAccount 
--group-container=cn=groups,cn=compat,dc=ipa,dc=math 
--group-objectclass=posixGroup


 But "ipa migrate-ds" fails with this message for each user :

   xxx: missing attribute "sn" required by object class 
"organizationalPerson"


with a final :

No users/groups were migrated from ldap://...:389

 I try with and without --with-compat option, and with 
ipa-compat-manage enabled and disabled.


 But when I look at ldap entries on the server in production, I see 
however a sn record (containing the last name) for each user. So where 
is the bug ?


Thanks,


Hi,

the command migrate-ds performs a search equivalent to
# ldapsearch -D "cn=Directory Manager" -W -b 
cn=users,cn=compat,dc=ipa,dc=math "(objectclass=posixAccount)"
in order to find the users to migrate. As the specified base DN is the 
compat tree (instead of cn=users,cn=accounts,dc=ipa,dc=math), only a 
subset of the attributes are visible.
Can you retry with --user-container=cn=users,cn=accounts,dc=ipa,dc=math 
and --group-container=cn=groups,cn=accounts,dc=ipa,dc=math?


flo
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] LDAP client problem after upgrade to 4.8.7

[Avi White via FreeIPA-users]

Hello.

I'm experiencing a LDAP client problem on CentOS 7 after upgrade of FreeIPA 
server from CentOS 8.2 (FreeIPA 4.8.4) to 8.3 (FreeIPA 4.8.7).

Here is what I was able to find. During login, nslcd on client performs LDAP 
bind using credentials provided by user. Here are the nslcd debug logs:

against 4.8.4 server, working:

nslcd: [8b4567]  DEBUG: 
ldap_simple_bind_s("uid=myuser,cn=users,cn=compat,dc=my,dc=org","***") 
(uri="ldap://ipa2.my.org;)
nslcd: [8b4567]  DEBUG: ldap_result(): 
uid=myuser,cn=users,cn=compat,dc=my,dc=org
nslcd: [8b4567]  DEBUG: ldap_unbind()
nslcd: [8b4567]  DEBUG: bind successful

against 4.8.7 server, not working:

nslcd: [b0dc51]  DEBUG: ldap_start_tls_s()
nslcd: [b0dc51]  DEBUG: 
ldap_simple_bind_s("uid=myuser,cn=users,cn=compat,dc=my,dc=org","***") 
(uri="ldap://ipa3.my.org;)
nslcd: [b0dc51]  ldap_result() failed: No such object
nslcd: [b0dc51]  uid=myuser,cn=users,cn=compat,dc=my,dc=org: 
lookup failed: No such object
nslcd: [b0dc51]  DEBUG: ldap_unbind()

I attempted to replicate what nslcd does using ldapsearch, and I could not find 
any difference between output from 4.8.4 and 4.8.7. I can bind as my user and 
run queries. I also checked the changelog between these server versions and 
could not find anything suspicious. Any suggestions how to deal with this? 
Thanks.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] HTTPD very busy while doing nothing - many processes

[lejeczek via FreeIPA-users]

hi guys

In a "healthy" domain I see on master(with KRA) which 
pretends to be very busy.


-> $ tailf /var/log/httpd/error_log
[Wed Dec 23 11:24:23.364388 2020] [core:notice] [pid 14691] 
AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
[Wed Dec 23 11:24:29.753445 2020] [mpm_prefork:notice] [pid 
14691] AH00171: Graceful restart requested, doing restart
[Wed Dec 23 11:24:33.027682 2020] 
[lbmethod_heartbeat:notice] [pid 14691] AH02282: No slotmem 
from mod_heartmonitor
[Wed Dec 23 11:24:33.128184 2020] [mpm_prefork:notice] [pid 
14691] AH00163: Apache/2.4.6 (CentOS) mod_auth_gssapi/1.5.1 
mod_nss/1.0.14 NSS/3.28.4 mod_wsgi/3.4 Python/2.7.5 
configured -- resuming normal operations
[Wed Dec 23 11:24:33.128244 2020] [core:notice] [pid 14691] 
AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
[Wed Dec 23 11:24:39.324905 2020] [mpm_prefork:notice] [pid 
14691] AH00171: Graceful restart requested, doing restart
[Wed Dec 23 11:24:42.535391 2020] 
[lbmethod_heartbeat:notice] [pid 14691] AH02282: No slotmem 
from mod_heartmonitor
[Wed Dec 23 11:24:42.598113 2020] [mpm_prefork:notice] [pid 
14691] AH00163: Apache/2.4.6 (CentOS) mod_auth_gssapi/1.5.1 
mod_nss/1.0.14 NSS/3.28.4 mod_wsgi/3.4 Python/2.7.5 
configured -- resuming normal operations
[Wed Dec 23 11:24:42.598152 2020] [core:notice] [pid 14691] 
AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
[Wed Dec 23 11:24:48.964880 2020] [mpm_prefork:notice] [pid 
14691] AH00171: Graceful restart requested, doing restart
[Wed Dec 23 11:24:51.385796 2020] [:error] [pid 8801] ipa: 
INFO: *** PROCESS START ***
[Wed Dec 23 11:24:52.319019 2020] 
[lbmethod_heartbeat:notice] [pid 14691] AH02282: No slotmem 
from mod_heartmonitor
[Wed Dec 23 11:24:52.389349 2020] [mpm_prefork:notice] [pid 
14691] AH00163: Apache/2.4.6 (CentOS) mod_auth_gssapi/1.5.1 
mod_nss/1.0.14 NSS/3.28.4 mod_wsgi/3.4 Python/2.7.5 
configured -- resuming normal operations
[Wed Dec 23 11:24:52.389404 2020] [core:notice] [pid 14691] 
AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
[Wed Dec 23 11:24:58.537949 2020] [mpm_prefork:notice] [pid 
14691] AH00171: Graceful restart requested, doing restart


And it does not seems to stop.

top agrees:

 8801 ipaapi    20   0  609384  48384   7244 R  19.2  0.8 
0:00.58 (wsgi:ipa) -DFOREGROUND
 8799 ipaapi    20   0  592932  42728   6560 R  16.2  0.7 
0:00.49 (wsgi:ipa) -DFOREGROUND
 8798 ipaapi    20   0  552124  29548   4892 R  15.9  0.5 
0:00.48 (wsgi:ipa) -DFOREGROUND
 8800 ipaapi    20   0  551736  29256   4836 R  14.9  0.5 
0:00.45 (wsgi:ipa) -DFOREGROUND
 8803 apache    20   0  458680  17568   4712 S   7.9  0.3 
0:00.24 /usr/sbin/httpd -DFOREGROUND
 8802 apache    20   0  458680  17568   4712 S   7.6  0.3 
0:00.23 /usr/sbin/httpd -DFOREGROUND
 8804 apache    20   0  458680  17568   4712 S   7.6  0.3 
0:00.23 /usr/sbin/httpd -DFOREGROUND
 8806 apache    20   0  458680  17568   4712 S   7.6  0.3 
0:00.23 /usr/sbin/httpd -DFOREGROUND
 8805 apache    20   0  458680  17568   4712 S   4.0  0.3 
0:00.12 /usr/sbin/httpd -DFOREGROUND
14691 root  20   0  431104  58988  49260 S   3.0  1.0 
0:40.05 /usr/sbin/httpd -DFOREGROUND
 8796 kdcproxy  20   0  626388  18812   4084 S   2.3  0.3 
0:00.07 (wsgi:kdcproxy) -DFOREGROUND
 8797 kdcproxy  20   0  691924  18812   4084 S   2.3  0.3 
0:00.07 (wsgi:kdcproxy) -DFOREGROUND


That surely is not normal behavior, right?
What here is the suspect I should start interrogating?
many thanks, L.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] "missing attribute sn" error on migration

[Jacquelin Charbonnel via FreeIPA-users]

Hi everyone,

	To create a nice new proper domain in CentOS8 (with a new name and so), I use 
"ipa migrate-ds" on a fresh installed Centos8 server, to retrieve entries from 
my current domain in CentOS7 :


ipa migrate-ds ldap://my_current_server:389 
--user-container=cn=users,cn=compat,dc=ipa,dc=math --bind-dn="cn=Directory 
Manager" --user-objectclass=posixAccount 
--group-container=cn=groups,cn=compat,dc=ipa,dc=math --group-objectclass=posixGroup


But "ipa migrate-ds" fails with this message for each user :

  xxx: missing attribute "sn" required by object class "organizationalPerson"

with a final :

No users/groups were migrated from ldap://...:389

	I try with and without --with-compat option, and with ipa-compat-manage enabled 
and disabled.


	But when I look at ldap entries on the server in production, I see however a sn 
record (containing the last name) for each user. So where is the bug ?


Thanks,

--
Jacquelin Charbonnel - (+33)2 4173 5397
CNRS Mathrice/LAREMA - Campus universitaire d'Angers
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: FreeIPA servers in different dns zones/domains but with the same realm

[Alexander Bokovoy via FreeIPA-users]

On ti, 22 joulu 2020, Juarez Souza Junior wrote:

Hi Alexander, thanks for answering.

I want to deploy a freeipa server for each domain (app.test.local,
dev.test.local, sec.test.local and etc) but with the same realm for users
to have the same user database between the servers.
Could it be possible?


Do not drop the mailing list.

I already answered your question. Please search the mailing list
archives for additional details if you did not understand the answer I
gave _after_ the reference to the archives.





Em ter., 22 de dez. de 2020 às 11:22, Alexander Bokovoy 
escreveu:


On ti, 22 joulu 2020, Juarez Souza Junior via FreeIPA-users wrote:
>Hi All! So I'm trying to deploy FreeIPA Servers (with integrated DNS
>Server) in a domain and subdomain with the same user realm.
>Anyone knows if it would be possible to deploy FreeIPA servers in
different
>domains but sharing the same realm?
>How could I deploy a replica without enrolling it to the same domain of
the
>master server?
>For example:
>IPA Server -> realm: TEST.LOCAL domain: test.local (10.1.1.0/24)
>REPLICA -> realm: TEST.LOCAL domain: app.test.local (10.1.2.0/24)
>
>My problem is: I'm working on a project where I have multiple domains
(app,
>sec, dev and etc) and I need centralized user authentication for each
>domain zone.
>
>I did some test labs without success. (mainly with the replica)
>
>I hope someone could give me a direction.

What exactly did you try?

Look at this list archives, this is one of often asked questions. You
*should not* specify --domain option to ipa-client-install to be your
client's domain: e.g. not --domain=app.test.local but instead
--domain=test.local. The hostname can be in any domain, as long as that
domain zone exists in DNS and if that domain zone is not managed by IPA
DNS server, then the host-to-be-enrolled hostname exists in that zone.



--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland




--
Atenciosamente,

Juarez Souza Junior





--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org