Trust fails between IPA 4.5.4 and Samba AD DC 4.8.1 (MIT Kerberos) -- CIFS server denied credentials
by Nathan Brown
When trying to establish an AD trust between IPA 4.5.4 and Samba 4.8.1
(MIT Kerberos), it fails with the following error:
[root@atlas5ipa samba]# ipa -vv trust-add ATLAS5.HPC
--range-type=ipa-ad-trust --two-way=true --admin=Administrator
--server dc.atlas5.hpc
Active Directory domain administrator's password:
ipa: ERROR: Insufficient access: CIFS server denied your credentials
IPA Server Versions
-------------------
root@atlas5ipa samba]# rpm -qa | grep ipa
python2-ipaclient-4.5.4-10.el7.centos.noarch
ipa-server-trust-ad-4.5.4-10.el7.centos.x86_64
python-ipaddress-1.0.16-2.el7.noarch
python-libipa_hbac-1.16.0-19.el7.x86_64
sssd-ipa-1.16.0-19.el7.x86_64
ipa-server-4.5.4-10.el7.centos.x86_64
ipa-python-compat-4.5.4-10.el7.centos.noarch
python-iniparse-0.4-9.el7.noarch
ipa-common-4.5.4-10.el7.centos.noarch
python2-ipaserver-4.5.4-10.el7.centos.noarch
ipa-client-4.5.4-10.el7.centos.x86_64
ipa-server-dns-4.5.4-10.el7.centos.noarch
libipa_hbac-1.16.0-19.el7.x86_64
ipa-server-common-4.5.4-10.el7.centos.noarch
python2-ipalib-4.5.4-10.el7.centos.noarch
ipa-client-common-4.5.4-10.el7.centos.noarch
[root@atlas5ipa samba]# rpm -qa | grep samba
samba-libs-4.7.1-6.el7.x86_64
samba-common-tools-4.7.1-6.el7.x86_64
samba-winbind-4.7.1-6.el7.x86_64
samba-client-libs-4.7.1-6.el7.x86_64
samba-4.7.1-6.el7.x86_64
samba-winbind-modules-4.7.1-6.el7.x86_64
samba-python-4.7.1-6.el7.x86_64
samba-common-libs-4.7.1-6.el7.x86_64
samba-common-4.7.1-6.el7.noarch
Samba DC Server Versions
------------------------
Samba 4.8.1 compiled with MIT Kerberos against GNUTLS 3.5.0
Note: The IPA server and Samba AD server are running on separate VM's.
Both have CentOS 7.3.1611 installed.
Here are the last few lines in the /var/log/httpd/error_log file from the
IPA server. You can see that information about both sides is being
exchanged but it ends up failing. --- signed SMB2 message
lsa_lsaRSetForestTrustInformation: struct lsa_lsaRSetForestTrustInformation
out: struct lsa_lsaRSetForestTrustInformation collision_info : *
collision_info : NULL result : NT_STATUS_OK rpc reply data:
lsa_QueryTrustedDomainInfoByName: struct lsa_QueryTrustedDomainInfoByName
in: struct lsa_QueryTrustedDomainInfoByName handle : * handle: struct
policy_handle handle_type : 0x00000000 (0) uuid :
00000016-0000-0000-f15a-25affc130000 trusted_domain : * trusted_domain:
struct lsa_String length : 0x0014 (20) size : 0x0014 (20) string : * string
: 'atlas5.hpc' level : LSA_TRUSTED_DOMAIN_INFO_FULL_INFO (8) signed SMB2
message lsa_QueryTrustedDomainInfoByName: struct
lsa_QueryTrustedDomainInfoByName out: struct
lsa_QueryTrustedDomainInfoByName info : * info : NULL result :
NT_STATUS_OBJECT_NAME_NOT_FOUND lsa_CreateTrustedDomainEx2: struct
lsa_CreateTrustedDomainEx2 in: struct lsa_CreateTrustedDomainEx2
policy_handle : * policy_handle: struct policy_handle handle_type :
0x00000000 (0) uuid : 00000016-0000-0000-f15a-25affc130000 info : * info:
struct lsa_TrustDomainInfoInfoEx domain_name: struct lsa_StringLarge length
: 0x0014 (20) size : 0x0016 (22) string : * string : 'atlas5.hpc'
netbios_name: struct lsa_StringLarge length : 0x000c (12) size : 0x000e
(14) string : * string : 'ATLAS5' sid : * sid :
S-1-5-21-600493320-3079828444-3896724992 trust_direction : 0x00000003 (3)
1: LSA_TRUST_DIRECTION_INBOUND 1: LSA_TRUST_DIRECTION_OUTBOUND trust_type :
LSA_TRUST_TYPE_UPLEVEL (2) trust_attributes : 0x00000000 (0) 0:
LSA_TRUST_ATTRIBUTE_NON_TRANSITIVE 0: LSA_TRUST_ATTRIBUTE_UPLEVEL_ONLY 0:
LSA_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN 0:
LSA_TRUST_ATTRIBUTE_FOREST_TRANSITIVE 0:
LSA_TRUST_ATTRIBUTE_CROSS_ORGANIZATION 0: LSA_TRUST_ATTRIBUTE_WITHIN_FOREST
0: LSA_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL 0:
LSA_TRUST_ATTRIBUTE_USES_RC4_ENCRYPTION auth_info_internal : *
auth_info_internal: struct lsa_TrustDomainInfoAuthInfoInternal auth_blob:
struct lsa_DATA_BUF2 size : 0x00000440 (1088) data : * data: ARRAY(1088)
access_mask : 0x00010000 (65536) 0: LSA_TRUSTED_QUERY_DOMAIN_NAME 0:
LSA_TRUSTED_QUERY_CONTROLLERS 0: LSA_TRUSTED_SET_CONTROLLERS 0:
LSA_TRUSTED_QUERY_POSIX 0: LSA_TRUSTED_SET_POSIX 0: LSA_TRUSTED_SET_AUTH 0:
LSA_TRUSTED_QUERY_AUTH signed SMB2 message lsa_CreateTrustedDomainEx2:
struct lsa_CreateTrustedDomainEx2 out: struct lsa_CreateTrustedDomainEx2
trustdom_handle : * trustdom_handle: struct policy_handle handle_type :
0x00000000 (0) uuid : 00000000-0000-0000-0000-000000000000 result :
NT_STATUS_ACCESS_DENIED [Tue May 08 10:07:34.739980 2018] [:error] [pid
3854] ipa: INFO: [jsonserver_session] admin(a)IPA.DOMAIN.COM:
trust_add/1(u'ATLAS5.HPC', realm_admin=u'Administrator',
realm_passwd=u'********', realm_server=u'dc.atlas5.hpc',
range_type=u'ipa-ad-trust', bidirectional=True, version=u'2.228'): ACIError
--- When you look at the Samba AD trust list, it shows the following entry.
If you delete the trust and try to add it again, the entry comes back.
[root@atlas5dc samba]# bin/samba-tool domain trust list Type[Forest]
Transitive[Yes] Direction[BOTH] Name[ipa.domain.com]
I have poured over this for days and cannot find a reason why it's
saying NT_STATUS_ACCESS_DENIED. I've tried verifying all the tedious
details like DNS SRV records and user SIDs, so now I feel like it's
going to be something more obvious :)
Thanks,
nate
5 years, 11 months
Problems Creating a Replica
by Brian Weaver
I had issues with my old FreeIPA installation so I rebuilt using Fedora 28
and FreeIPA 4.6 from the COPR of @freeipa/freeipa-4-6.
I managed successfully setup the server and import my DNS data. Now when I
try to create a replica it is blowing up. When I run "ipa-replica-install
--principal admin(a)IPA.${DOMAIN} -w 'uber-secret-password' -N" it's failing.
I've tried Google, cleaned up the directory of the server entries, etc. I'm
at an impass.
Here is the error
Done configuring Kerberos KDC (krb5kdc).
Configuring kadmin
[1/2]: starting kadmin
[2/2]: configuring kadmin to start on boot
Done configuring kadmin.
Configuring directory server (dirsrv)
[1/3]: configuring TLS for DS instance
[error] RuntimeError: Certificate issuance failed (CA_REJECTED)
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
I was going to get the error from the log directory. I ran uninstall before
I thought about it. Then when I try again it fails on "entry already
exists". So when I run uninstall again I have to do 'ipa server-del
ipa-server1.ipa.domain'.
I'm having no luck and it fails at random places. For example after the
last cleanup I got "Insufficient Access" with write privilege on
cn=replication,cn=etc,dc=ipa,dc=$domain'
Any help would really be appreciated. This is really holding me up.
--
/* insert witty comment here */
5 years, 11 months
New server, can't set passwords
by Bret Wortman
I've just finished setting up a new IPA server, planning to use it and
some replicas to replace our existing servers. I did this by dumping all
the data from the old ones using a series of ipa commands and then used
custom parsers to re-create the entries on the new one (so as not to
propagate our lack of CA into the new servers).
When I went to set new passwords on all the migrated accounts, I get
this error in the web ui: "IPA Error 4031: EmptyResult no matching entry
found".
The CLI results in this:
# ipa user-mod homer --random
ipa: ERROR: Operations error: key encryption/encoding failed
Any idea what might cause this and how I should fix it?
--
photo
*Bret Wortman*
Founder, Damascus Products LLC
855-644-2783 <tel:855-644-2783> | 303-523-8037 <tel:303-523-8037> |
bret(a)damascusproducts.com <mailto:bret@damascusproducts.com>
http://damascusproducts.com/
10332 Main St Suite 319 Fairfax, VA 22030
<http://facebook.com/wrapbuddiesco>
<http://www.linkedin.com/in/bretwortman>
<http://twitter.com/wrapbuddiesco>
<http://instagram.com/wrapbuddies>
5 years, 11 months
Fedora 28 / FreeIPA note
by Alexander Bokovoy
Hi,
Fedora project has released Fedora 28 last week. Unfortunately, FreeIPA
4.6.90.pre1 in Fedora 28 is not ready for production. We do not
recommend to upgrade to Fedora 28 on your FreeIPA masters at this time.
We are working on finalizing FreeIPA 4.7 release that should replace
4.6.90.pre1 in Fedora 28. Right now the delta between Fedora 28 alpha
where 4.6.90.pre1 was released and FreeIPA git master is about two
months of work and dozens of fixes, including fixes for upgrade
issues.
The reason why FreeIPA 4.7 is delayed is due to a need to coordinate
with a number of other projects. FreeIPA moved to mod_ssl; Fedora 28
moved to use SQL backend in nss as a new default which broke a lot of
assumptions in both FreeIPA and Dogtag. Tomcat version was upgrade and
Dogtag needed to adapt which all took a lot of time. Unfortunately, some
issues could only be discovered when you are moving forward past the
fixes already made, so we are in a ping-pong game across a number of
projects.
A nightly CI was added to FreeIPA upstream which allows us to test a
wider set of configurations against Fedora 27 and 28.
We are planning to release another FreeIPA 4.7 prelease this week. It
should help with a general upgrade path stabilization from Fedora 27 to
28.
Thus, I'd recommend to not upgrade to Fedora 28 until we provide an
additional guidance.
Thank you,
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
5 years, 11 months
Re: Can't install CA from replica file - Failed to import EncryptedPrivateKeyInfo to token
by H. Frenzel
Am 01.05.2018 09:33, schrieb Fraser Tweedale via FreeIPA-users:
>> ipa : DEBUG stderr=TokenException: Failed to import
>> EncryptedPrivateKeyInfo to token: (-8152) The key does not support
>> the
>> requested operation.
> 1. Clean up the failed replica via `ipa-server-install --uninstall`.
> You may need to use `ipa-replica-manage del` or `ipa server-del`
> as well, to clean up replication agreeements.
>
> 2. Restart Dogtag on the master. (But before you do, out of
> interest, what is Dogtag's uptime?)
>
> 3. Attempt replica installation again.
I did the above few times. The recent dogtag uptime was 7h.
# service pki-tomcatd@pki-tomcat status
Redirecting to /bin/systemctl status pki-tomcatd(a)pki-tomcat.service
● pki-tomcatd(a)pki-tomcat.service - PKI Tomcat Server pki-tomcat
Loaded: loaded (/lib/systemd/system/pki-tomcatd@.service; enabled;
vendor preset: disabled)
Active: active (running) since Mi 2018-05-02 06:30:44 CEST; 7h ago
Process: 13876 ExecStartPre=/usr/bin/pkidaemon start %i (code=exited,
status=0/SUCCESS)
Main PID: 14018 (java)
> Also, see if regular certificate issuance works on the master. (The
> other times I saw this error, it was in fact a total failure of the
> signing operation on the CA master, and nothing to do with replica
> installation specifically.)
Certificate issuance works as far as I could see. I tried with
'ipa-getcert request -d /tmp/test' and checked with:
# ipa-getcert request -d /tmp/test
Request ID '20180502121204':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/tmp/test',nickname='test',token='NSS Certificate
DB'
certificate:
type=NSSDB,location='/tmp/test',nickname='test',token='NSS Certificate
DB'
CA: IPA
issuer: CN=Certificate Authority,O=EXAMPLE.COM
subject: CN=ipa-01.example.com,O=EXAMPLE.COM
expires: 2020-05-02 12:12:05 UTC
dns: ipa-01.example.com
principal name: host/ipa-01.example.com(a)EXAMPLE.COM
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
> If replica installation fails after the above steps, please provide
> the /var/log/pki/pki-tomcat/ca/debug logs from both the master and
> the replica-to-be.
I tried it again to produce the requested logs. I did the following
steps:
1. on master: ipa-replica-prepare (s.
pki-tomcat_ca_debug.log.ipa-replica-prepare.1.gz)
2. on replica: ipa-replica-install
This failed with
'ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall):
ERROR cannot connect to 'ldaps://ipa-01.example.com': TLS error
-8172:Peer's certificate issuer has been marked as not trusted by the
user.'
Then I needed to perform the following steps to get it to work
(reproducable each time - both steps are required)
3. on master: ipa-server-upgrade (s.
pki-tomcat_ca_debug.log.ipa-server-upgrade.gz)
4. on master: ipa-certupdate (s.
pki-tomcat_ca_debug.log.ipa-certupdate.gz)
After this, I retried:
5. on master: ipa-replica-prepare (s.
pki-tomcat_ca_debug.log.ipa-replica-prepare.2.gz)
6. on replica: ipa-replica-install (s.
pki-tomcat_ca_debug.log.ipa-replica-install.2.gz)
This worked, so I tried to install the CA replication
7. on replica: ipa-ca-install (s.
pki-tomcat_ca_debug.log.ipa-ca-install.2)
This failed again with 'ipa : DEBUG
stderr=TokenException: Failed to import EncryptedPrivateKeyInfo to
token: (-8152) The key does not support the requested operation.'
There is no /var/log/pki/pki-tomcat/ca/debug created on the replica,
but I attached the pki-ca-spawn.20180502135730.log.gz.
Thx for help
H.
5 years, 11 months
Fedora 28 as a FreeIPA desktop client
by Alex Corcoles
Hi,
I'm running Fedora 27 as my main desktop enrolled on my FreeIPA domain
for a while and it's awesome. I was toying with the idea of building a
cloud VM as a remote desktop, but xrdp is a bit annoying on Fedora 27
so I postponed that.
Now I'm playing with Fedora 28 on a VM, where xrdp works *beautifully*
but I have a couple of annoyances with FreeIPA integration:
* Gnome Keyring prompts me for a password, when I think in Fedora 27
was integrated into FreeIPA (or at least, I don't think I see password
prompts)
* I just dnf updated, but I used to get a colord elevation prompt on
login, which I couldn't get to work (i.e. it doesn't pick up my
password)
* Gnome elevation prompts (such as Gnome Software) as for the
credentials of the user I created during system installation, instead
of my FreeIPA user
sudo is working on the console perfectly through FreeIPA.
Are those known issues? Is there any useful troubleshooting I can do?
Cheers,
Álex
--
___
{~._.~}
( Y )
()~*~() mail: alex at corcoles dot net
(_)-(_) http://alex.corcoles.net/
5 years, 11 months
https://www.freeipa.org/page/V4/Authselect_migration review
by Rob Crittenden
Not sure worth adding but `authselect list` will show available profiles.
I think commands should use a <code> tag rather than bold (authselect
select sssd with-mkhomedir).
The NIS domain change is mentioned but not the proposed or actual solution.
rob
5 years, 11 months
Named not pulling authoritative zones from LDAP
by Matt Ungaro
Hello there,
Having an issue with named on one of our IPA servers. Our IPA server gets
the following messages in named.run when it starts:
0 master zones from LDAP instance 'ipa' loaded (0 zones defined, 0
inactive, 0 failed to load)
0 master zones is suspicious number, please check access control
instructions on LDAP server
We have been rolling through and upgrading our IPA infrastructure, and it
looks like DNS privileges were lost for this host during the upgrade, and
the issue was exposed on a restart of named. We're looking to get this
server back into the proper pbac group so that it can read in authoritative
zones. Any assistance is greatly appreciated!
Host information:
Upgraded from 4.2.0-15 to 4.5.0-22
OS Version: CentOS 7.2.1511
Issue description:
named starts, but cannot get authoritative zones from LDAP. Kerberos
authentication is functioning (Tested using the named.keytab and ldapsearch
as shown below), but the host does not have DNS Server privileges. Followed
troubleshooting steps located at:
https://docs.pagure.org/bind-dyndb-ldap/BIND9/NamedCannotStart.html
Domain name has been scrubbed, but host names are intact. I assure you, we
are not example.net. :)
In any of this output we are looking for ipa-002.example.net.
From the non-functioning host (FreeIPA version 4.5):
> kinit -kt /etc/named.keytab DNS/ipa-002.example.net
> ldapsearch -H 'ldapi://%2fvar%2frun%2fslapd-EXAMPLE-NET.socket' -Y GSSAPI
-b 'cn=dns,dc=example,dc=net'
SASL/GSSAPI authentication started
SASL username: DNS/ipa-002.example.net(a)EXAMPLE.NET
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <cn=dns,dc=example,dc=net> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# dns, example.net
dn: cn=dns,dc=example,dc=net
cn: dns
objectClass: idnsConfigObject
objectClass: nsContainer
objectClass: ipaConfigObject
objectClass: top
objectClass: ipadnscontainer
# sec, dns, example.net
dn: cn=sec,cn=dns,dc=example,dc=net
cn: sec
objectClass: nsContainer
objectClass: top
# keys, sec, dns, example.net
dn: cn=keys,cn=sec,cn=dns,dc=example,dc=net
cn: keys
objectClass: nsContainer
objectClass: top
# servers, dns, example.net
dn: cn=servers,cn=dns,dc=example,dc=net
cn: servers
objectClass: nsContainer
objectClass: top
# servers + 79ae4ffe-6b7211e7-9fb996c1-641091b3, dns, example.net
dn:
cn=servers+nsuniqueid=79ae4ffe-6b7211e7-9fb996c1-641091b3,cn=dns,dc=example
,dc=net
cn: servers
objectClass: nsContainer
objectClass: top
# search result
search: 4
result: 0 Success
# numResponses: 6
# numEntries: 5
> ipa privilege-show 'DNS Servers' --all --raw
dn: cn=DNS Servers,cn=privileges,cn=pbac,dc=example,dc=net
cn: DNS Servers
description: DNS Servers
member: krbprincipalname=DNS/ipa-001.example.net(a)EXAMPLE.NET
,cn=services,cn=accounts,dc=example,dc=net
member: krbprincipalname=ipa-dnskeysyncd/ipa-001.example.net(a)EXAMPLE.NET
,cn=services,cn=accounts,dc=example,dc=net
member: krbprincipalname=DNS/eu-ipa-02.example.net(a)EXAMPLE.NET
,cn=services,cn=accounts,dc=example,dc=net
member: krbprincipalname=ipa-dnskeysyncd/eu-ipa-02.example.net(a)EXAMPLE.NET
,cn=services,cn=accounts,dc=example,dc=net
member: krbprincipalname=DNS/eu-ipa-01.example.net(a)EXAMPLE.NET
,cn=services,cn=accounts,dc=example,dc=net
member: krbprincipalname=ipa-dnskeysyncd/eu-ipa-01.example.net(a)EXAMPLE.NET
,cn=services,cn=accounts,dc=example,dc=net
member: krbprincipalname=DNS/dev-ipa-01.mgmt.example.net(a)EXAMPLE.NET
,cn=services,cn=accounts,dc=example,dc=net
member: krbprincipalname=ipa-dnskeysyncd/
dev-ipa-01.mgmt.example.net(a)EXAMPLE.NET
,cn=services,cn=accounts,dc=example,dc=net
member: krbprincipalname=DNS/rslon-ipa-01.mgmt.example.net(a)EXAMPLE.NET
,cn=services,cn=accounts,dc=example,dc=net
member: krbprincipalname=ipa-dnskeysyncd/
rslon-ipa-01.mgmt.example.net(a)EXAMPLE.NET
,cn=services,cn=accounts,dc=example,dc=net
member: krbprincipalname=DNS/rslon-ipa-02.mgmt.example.net(a)EXAMPLE.NET
,cn=services,cn=accounts,dc=example,dc=net
member: krbprincipalname=ipa-dnskeysyncd/
rslon-ipa-02.mgmt.example.net(a)EXAMPLE.NET
,cn=services,cn=accounts,dc=example,dc=net
member: krbprincipalname=DNS/rsiad-ipa-02.mgmt.example.net(a)EXAMPLE.NET
,cn=services,cn=accounts,dc=example,dc=net
member: krbprincipalname=ipa-dnskeysyncd/
rsiad-ipa-02.mgmt.example.net(a)EXAMPLE.NET
,cn=services,cn=accounts,dc=example,dc=net
member: krbprincipalname=DNS/rsiad-ipa-01.mgmt.example.net(a)EXAMPLE.NET
,cn=services,cn=accounts,dc=example,dc=net
member: krbprincipalname=ipa-dnskeysyncd/
rsiad-ipa-01.mgmt.example.net(a)EXAMPLE.NET
,cn=services,cn=accounts,dc=example,dc=net
member: krbprincipalname=DNS/rsdfw-ipa-01.mgmt.example.net(a)EXAMPLE.NET
,cn=services,cn=accounts,dc=example,dc=net
member: krbprincipalname=ipa-dnskeysyncd/
rsdfw-ipa-01.mgmt.example.net(a)EXAMPLE.NET
,cn=services,cn=accounts,dc=example,dc=net
member: krbprincipalname=DNS/rsdfw-ipa-02.mgmt.example.net(a)EXAMPLE.NET
,cn=services,cn=accounts,dc=example,dc=net
member: krbprincipalname=ipa-dnskeysyncd/
rsdfw-ipa-02.mgmt.example.net(a)EXAMPLE.NET
,cn=services,cn=accounts,dc=example,dc=net
member: krbprincipalname=DNS/prod-ipa-01.mgmt.example.net(a)EXAMPLE.NET
,cn=services,cn=accounts,dc=example,dc=net
member: krbprincipalname=ipa-dnskeysyncd/
prod-ipa-01.mgmt.example.net(a)EXAMPLE.NET
,cn=services,cn=accounts,dc=example,dc=net
memberof: cn=System: Read DNS
Configuration,cn=permissions,cn=pbac,dc=example,dc=net
memberof: cn=System: Write DNS
Configuration,cn=permissions,cn=pbac,dc=example,dc=net
memberof: cn=System: Add DNS
Entries,cn=permissions,cn=pbac,dc=example,dc=net
memberof: cn=System: Manage DNSSEC
keys,cn=permissions,cn=pbac,dc=example,dc=net
memberof: cn=System: Manage DNSSEC
metadata,cn=permissions,cn=pbac,dc=example,dc=net
memberof: cn=System: Read DNS
Entries,cn=permissions,cn=pbac,dc=example,dc=net
memberof: cn=System: Remove DNS
Entries,cn=permissions,cn=pbac,dc=example,dc=net
memberof: cn=System: Update DNS
Entries,cn=permissions,cn=pbac,dc=example,dc=net
memberof: cn=System: Read DNS Servers
Configuration,cn=permissions,cn=pbac,dc=example,dc=net
objectClass: top
objectClass: groupofnames
objectClass: nestedgroup
--
Matt Ungaro (mungaro(a)armsbusinesssolutions.com)
Phone: 608-616-5367
Engineer 3
ARMS Business Solutions
--
IMPORTANT: This e-mail (including
any attachments) is intended for
the use of
the individual or entity to which it is addressed and may
contain information
that is classified, private, or confidential. If the
reader of this message is
not the intended recipient, or the employee or
agent responsible for delivering
the message to the intended recipient, you
are hereby notified that any
dissemination, distribution, or copying of
this communication is prohibited. If
you have received this communication
in error, please notify us immediately by
replying to this e-mail. Thank
you.
5 years, 11 months
Problems setting up replica on Raspberry Pi 3B (ARM)
by Jonathan Vaughn
Yes, I know, not recommended etc, low performance. I'm not going to run the
CA on it. I just want to have a backup LDAP/Kerberos server.
Right now I'm just trying to test things out. I've got a master and a
replica (so you could say two masters I suppose) running in Virtualbox VMs,
and I'm trying to set up a 3rd replica on a Pi. All are Fedors 27. I had to
downgrade httpd due to https://pagure.io/freeipa/issue/7493 to even set up
the first VM replica, but this issue is separate.
Currently, the problem is it can't connect to it's own LDAP instance due to
some kind of error ... ipa-replica-install worked fine on the x86_64 VM but
on the armv71 Pi 3B when it tries to connect to LDAPI instead of
using 'ldapi:///var/run//slapd-COMPANY-INTERNAL.socket' it
uses 'ldapi://%2Fvar%2Frun%2Fslapd-COMPANY-INTERNAL.socket'.
So it seems there is yet another ARM (or non-x86_64) bug ... similar to the
problem with httpd and passing the KRB5CCNAME properly
https://pagure.io/freeipa/issue/7337
Any ideas on where to look to patch in a fix to this so it uses the correct
filename? The socket file is there ... and (at the time it tries) LDAP is
running.
5 years, 11 months
