Hi Alexander,

I've changed the names to anonymize the logs, but have maintained the
structure of the names.

This is how I've got the hostname configured:

>> [root@freeipaserver ~]# hostname
>> freeipaserver
>> [root@freeipaserver ~]# hostname -a
>> freeipaserver
>> [root@freeipaserver ~]# hostname -f
>> freeipaserver.my.sub.domain.com
>> [root@freeipaserver ~]# cat /etc/hosts
>> 127.0.0.1   localhost localhost.localdomain localhost4
localhost4.localdomain4
>> ::1         localhost localhost.localdomain localhost6
localhost6.localdomain6
>>
>> 192.168.1.10 freeipaserver.my.sub.domain.com freeipaserver
>>
>> [root@freeipaserver ~]# cat /etc/sysconfig/network
>> DNS1=192.168.10.1
>> NISDOMAIN=my.sub.domain.com
>> GATEWAY=192.168.1.1
>> SEARCH=my.sub.domain.com
>> DOMAIN=my.sub.domain.com

(NISDOMAIN and DOMAIN were previous attempts to set the domain.  I can't
just set /etc/hostname to "freeipaserver" as a bash prompt that says [
r...@freeipaserver.my.sub.domain.com ~] is unacceptable to our ops teams,
and we can't rewrite our bashrcs (these are company standards).  However,
based on the instructions, I do believe I've set the hostname correctly
unless something has changed between RHEL6 and RHEL7).

Thanks,
Jon A

On Wed, Jan 27, 2016 at 2:44 PM, Alexander Bokovoy <aboko...@redhat.com>
wrote:

> On Wed, 27 Jan 2016, Jon wrote:
>
>> Hello,
>>
>> Thanks for your feedback.
>>
>> So I reran `ipa-adtrust-install` and got a core dump from samba that there
>> was no space left on the device...?
>>
>> A little digging showed that /var/log had filled up with files named
>> "core.XXXXX" in /var/log/samba/cores/winbindd.  So I removed all of them
>> and reran `ipa-adtrust-install --add-sids` which continues to fail on
>> starting CIFS services.  Debug information shows that it's the smb service
>> that isn't starting:
>>
>>   [22/22]: starting CIFS services
>>>> ipa         : DEBUG    Starting external process
>>>> ipa         : DEBUG    args='/bin/systemctl' 'start' 'smb.service'
>>>> ipa         : DEBUG    Process finished, return code=1
>>>> ipa         : DEBUG    stdout=
>>>> ipa         : DEBUG    stderr=Job for smb.service failed because the
>>>>
>>> control process exited with error code. See "systemctl status
>> smb.service"
>> and "journalctl -xe" for details.
>>
>>>
>>>> ipa         : CRITICAL CIFS services failed to start
>>>> ipa         : DEBUG      duration: 16 seconds
>>>> ipa         : DEBUG    Done configuring CIFS.
>>>>
>>>
>> Looking at the samba logs, I see:
>>
>> Jan 27 13:19:48 freeipa01enwdco smbd[18300]: [2016/01/27
>>>>
>>> 13:19:48.482378,  0] ipa_sam.c:4208(bind_callback_cleanup)
>>
>>> Jan 27 13:19:48 freeipa01enwdco smbd[18300]:   kerberos error:
>>>>
>>> code=-1765328203, message=Keytab contains no suitable keys for cifs/
>> freeipaser...@my.sub.domain.com
>>
> ^ is this the real name for the server? E.g. it is non-fully qualified
> one here? What does your `hostname` command show?
>
>
> Jan 27 13:19:49 freeipa01enwdco smbd[18300]: [2016/01/27
>>>>
>>> 13:19:49.482818,  0] ipa_sam.c:4520(pdb_init_ipasam)
>>
>>> Jan 27 13:19:49 freeipa01enwdco smbd[18300]:   Failed to get base DN.
>>>> Jan 27 13:19:49 freeipa01enwdco smbd[18300]: [2016/01/27
>>>>
>>> 13:19:49.482909,  0]
>> ../source3/passdb/pdb_interface.c:179(make_pdb_method_name)
>>
>>> Jan 27 13:19:49 freeipa01enwdco smbd[18300]:   pdb backend
>>>>
>>> ipasam:ldapi://%2fvar%2frun%2fslapd-MY-SUB-DOMAIN-COM.socket did not
>> correctly init (error was NT_STATUS_UNSUCCESSFUL)
>>
>>> Jan 27 13:19:49 freeipa01enwdco systemd[1]: smb.service: main process
>>>>
>>> exited, code=exited, status=1/FAILURE
>>
>>> Jan 27 13:19:49 freeipa01enwdco systemd[1]: Failed to start Samba SMB
>>>>
>>> Daemon.
>>
>>> Jan 27 13:19:49 freeipa01enwdco systemd[1]: Unit smb.service entered
>>>>
>>> failed state.
>>
>>> Jan 27 13:19:49 freeipa01enwdco systemd[1]: smb.service failed.
>>>>
>>>
>>
>> I tried following the trust debugging instructions here:
>> http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_trust
>>
>> But it fails on the step `systemctl start smb winbind`
>>
>> # systemctl stop smb winbind
>>>> # net conf setparm global 'log level' 100
>>>> # nano /usr/share/ipa/smb.conf.empty
>>>> # rm /var/log/samba/log.*
>>>> # systemctl start smb winbind
>>>> Job for smb.service failed because the control process exited with error
>>>>
>>> code. See "systemctl status smb.service" and "journalctl -xe" for
>> details.
>>
>> Which produces the exact same error listed above.
>>
>>
>> in /var/log/samba/log.smbd I see what appears to be a stack trace, I see
>> the same exact error above as well as the error about the socket not
>> initing correctly:
>>
>> [2016/01/27 13:26:21.606257,  0, pid=18344, effective(0, 0), real(0, 0)]
>>>>
>>> ipa_sam.c:4208(bind_callback_cleanup)
>>  kerberos error: code=-1765328203, message=Keytab contains no suitable
>> keys for cifs/freeipaser...@my.sub.domain.com
>>
>>> [2016/01/27 13:26:21.606422,  2, pid=18344, effective(0, 0), real(0, 0)]
>>>>
>>> ../source3/lib/smbldap.c:998(smbldap_connect_system)
>>  failed to bind to server
>> ldapi://%2fvar%2frun%2fslapd-MY-SUB-DOMAIN-COM.socket with dn="[Anonymous
>> bind]" Error: Local error
>>        (unknown)
>>
>>> [2016/01/27 13:26:22.606842,  0, pid=18344, effective(0, 0), real(0, 0),
>>>>
>>> class=passdb] ../source3/passdb/pdb_interface.c:179(make_pdb_method_name)
>>  pdb backend ipasam:ldapi://%2fvar%2frun%2fslapd-MY-SUB-DOMAIN-COM.socket
>> did not correctly init (error was NT_STATUS_UNSUCCESSFUL)
>>
>> So I think the problem is more fundamental than trusts as samba won't even
>> start.
>>
>> Is there any documentation or does anyone have some good tricks for
>> troubleshooting samba?
>>
>> Thanks,
>> Jon A
>>
>> On Wed, Jan 20, 2016 at 4:57 AM, Alexander Bokovoy <aboko...@redhat.com>
>> wrote:
>>
>> 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
>>
>
>
> --
> / 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