On Wed, 20 Jan 2016, Anon Lister wrote:
So I had the same problem. For me it ended up being that some attribute was
not created correctly in 389 using the instructions in the guide. I don't
remember what it was off the top of my head. Something about a default user
or group SID I think. Had to turn samba logging up. Eventually it shows the
attribute it is failing on. I ended up manually adding it with vildap and
it worked fine after that. If noone else gets it I'll poke around and see
if I can find what it was, took me several hours to debug due to the
somewhat misleading error message.
The message is the only thing we get from Samba Python libraries, so it
is as good as what we get.

Use
http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_trust
to produce debug output needed to find out where things happened.

If your setup lacks 'Default SMB Group' group with a SID
(ipaNTSecurityIdentifier attribute), run ipa-adtrust-install --add-sids.

ipa-adtrust-install can be re-run several times to fix missing parts. It
skips steps which were already done and only performs those that are
really needed.

However, if your base IPA deployment does not work, like in the Jon's
case, there is little reason to run any of ipa-adtrust-install or other
trust-related functions.

Additionally, DNS should be configured properly. ipa-adtrust-install
either automatically updates IPA DNS (if IPA manages the DNS zone) or
produces list of entries that should be added to the DNS zone whoever
manages it. This should not be overlooked -- when Active Directory
domain controller tries to validate the trust, it uses DNS SRV records
to find out IPA domain controllers ('trust controllers' in IPA speak,
the ones where ipa-adtrust-install was run) and only considers those
that are available via SRV records. If AD DC cannot find IPA DC via SRV
record, trust cannot be validated.

On Jan 19, 2016 1:37 PM, "Jon" <three1...@gmail.com> wrote:

Hello,

While following the guide on setting up FreeIPA with AD
<http://www.freeipa.org/page/Active_Directory_trust_setup>, I got to the
step where I'm adding the AD trust to FreeIPA but I receive an error:

  >> Active Directory domain administrator's password:
  >> ipa: ERROR: CIFS server communication error: code "-1073741801",
  >>                 message "Memory allocation error" (both may be "None")

Thinking that the error was what was stated (my VM at the time only had
1GB of ram), I shutdown my VM (memory hot add was not enabled in VMware, it
is now), bumped the RAM to 4GB, and booted the VM.

Upon running the same command after reboot I received an error:

  >> ipa: ERROR: did not receive Kerberos credentials

kinit admin is also reporting an error:

  >>  kinit: Cannot contact any KDC for realm 'myrealm'  while getting
initial credentials

trying to start FreeIPA in debug mode identified the samba service as at
fault.

  >> Jan 19 10:19:50 myfreeipaserver smbd[3676]:   kerberos error:
code=-1765328203, message=Keytab contains no suitable keys for cifs/
myfreeipaser...@sub.domain.mydomain.com
  >> Jan 19 10:19:51 myfreeipaserver smbd[3676]: [2016/01/19
10:19:51.261648,  0] ipa_sam.c:4520(pdb_init_ipasam)
  >> Jan 19 10:19:51 myfreeipaserver smbd[3676]:   Failed to get base DN.
  >> Jan 19 10:19:51 myfreeipaserver smbd[3676]: [2016/01/19
10:19:51.262675,  0]
../source3/passdb/pdb_interface.c:179(make_pdb_method_name)
  >> Jan 19 10:19:51 myfreeipaserver smbd[3676]:   pdb backend
ipasam:ldapi://%2fvar%2frun%2fslapd-SUB-DOMAIN-MYDOMAIN-COM.socket did not
correctly init (error was NT_STATUS_UNSUCCESSFUL)

Googling for these errors turned up a few similar threads but none of the
solutions seemed to work and all signs pointed to AD integration as the
culprit...

So I did what any good sysadmin would do and forced freeipa to start while
ignoring any failures.  Every service except samba starts without issue.

So I tried my trust connection again, and received the same error,

  >> Active Directory domain administrator's password:
  >> ipa: ERROR: CIFS server communication error: code "-1073741801",
  >>                 message "Memory allocation error" (both may be "None")

Which brought me to googling two bug reports opened on this exact issue:

>> https://bugzilla.redhat.com/show_bug.cgi?id=878168
>> https://fedorahosted.org/freeipa/ticket/3266

Both of these bug reports indicate there's an upstream bug in Samba, the
bug has been closed and reopened at least once.  I did add the AD servers
to /etc/hosts and rebooted the server.  I have to go through the same
process of forcing freeipa to start after the server rebooted... However, I
received the same error message.

While the bug report is currently closed, I seem to be experiencing the
same issues...

Given this bug report, can you please answer me these questions three:

1)  Given the issues with Samba starting after reboot, is this bug report
actually what's wrong or is the error message when trying to create a trust
a red herring and it's actually samba that's the problem?
2)  Does this bug report mean that trusts between FreeIPA and AD are
broken and can not be established until the upstream bug in Samba is fixed?
3)  Is there a workaround?  (as adding the domain controllers to
/etc/hosts with IPv4 address does not appear to work)

System Stats:
- AD Server:  Win2k8R2
- FreeIPA server:

>> CentOS Linux release 7.2.1511 (Core)


>> # uname -a
>> Linux myserver 3.10.0-327.4.4.el7.x86_64 #1 SMP Tue Jan 5 16:07:00 UTC
2016 x86_64 x86_64 x86_64 GNU/Linux

>> # rpm -qa | grep ipa
>> python-libipa_hbac-1.13.0-40.el7_2.1.x86_64
>> ipa-server-4.2.0-15.el7.centos.3.x86_64
>> ipa-server-dns-4.2.0-15.el7.centos.3.x86_64
>> python-iniparse-0.4-9.el7.noarch
>> libipa_hbac-1.13.0-40.el7_2.1.x86_64
>> sssd-ipa-1.13.0-40.el7_2.1.x86_64
>> ipa-python-4.2.0-15.el7.centos.3.x86_64
>> ipa-client-4.2.0-15.el7.centos.3.x86_64
>> ipa-server-trust-ad-4.2.0-15.el7.centos.3.x86_64
>> ipa-admintools-4.2.0-15.el7.centos.3.x86_64


I appreciate any help.  I've been trying to get FreeIPA going for a couple
of weeks now and have run into nothing but frustrations.  The funny thing
is, I've never had a problem deploying FreeIPA by itself...  Microsoft
seems to be the common denominator in my hair pulling lately... Correlation
does not equal causation... but it sure is a coincidence...  :)

Thanks for your time!

Best Regards,
Jon A


--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to