gc-wip trying to reproduce demos from samba XP

[fixerivan]

I am trying to reproduce the super cool demos you showed at samba XP described here (https://sambaxp.org/archive-data-samba/sxp20/sxp20-d2/sxp20-d2t2-1-bokovoy-blancrenaud-FreeIPA-Catalog.pdf)

but when I try to add user from IPA into the remote desktop users group I am always getting

this is when i try to add the user to the group via AD Administrative center

if I try to add the IPA user via system properties / remote i get

would love to see this function properly, let me know if i can help you to debug this / provide more info if needed

trust is setup and verified, I am able to login to Windows via local login

global catalog was installed as part of the ipa trust-add command

thanks

[abbra]

You need to use abbra/gc-wip COPR repo on top of Fedora 32. That repository contains Samba with additional wip patches. The repo also contains FreeIPA package rebuilt on every commit to this tree to gc-wip branch.

You'd need to install gc with ipa-adtrust-install.

[fixerivan]

thank you for your fast reply but somehow I am still unable to get it work, here is what i am doing, lines deemed not important omitted for brevity:

xclbr.test is AD DC (192.168.1.223) exc.local is freeIPA DC (192.168.1.120)

on AD DC i set: dnscmd 127.0.0.1 /ZoneAdd EXC.LOCAL /Forwarder 192.168.1.120

on the freeIPA machine (clean latest fedora server VM):

*_sudo dnf copr enable abbra/gc-wip sudo dnf install rpm-build git clone https://github.com/abbra/freeipa.git -b gc-wip cd freeipa dnf builddep -b -D "with_wheels 1" -D "with_lint 1" --spec freeipa.spec.in --best --allowerasing --setopt=install_weak_deps=False ./makerpms.sh dnf install dist/rpms/.rpm_**

systemctl stop firewalld systemctl disable firewalld systemctl mask --now firewalld

ipa-server-install

The IPA Master Server will be configured with: Hostname: ipa.exc.local IP address(es): 192.168.1.120 Domain name: exc.local Realm name: EXC.LOCAL

The CA will be configured with: Subject DN: CN=Certificate Authority,O=EXC.LOCAL Subject base: O=EXC.LOCAL Chaining: self-signed

BIND DNS server will be configured to serve IPA domain with: Forwarders: No forwarders Forward policy: only Reverse zone(s): No reverse zone

here i disable DNSSEC via editing /etc/named/ipa-options-ext.conf via dnssec-enable no; dnssec-validation no; as my AD DC somehow doesn't want to function properly with DNSSEC, just to be sure after the change of named config i reboot

kinit admin

ipa dnsforwardzone-add XCLBR.TEST --forwarder=192.168.1.223 --forward-policy=only Server will check DNS forwarder(s). This may take some time, please wait ... Zone name: xclbr.test. Active zone: TRUE Zone forwarders: 192.168.1.223 Forward policy: only

ping xclbr.test PING xclbr.test (192.168.1.223) 56(84) bytes of data. 64 bytes from 192.168.1.223 (192.168.1.223): icmp_seq=1 ttl=128 time=0.218 ms 64 bytes from 192.168.1.223 (192.168.1.223): icmp_seq=2 ttl=128 time=0.428 ms 64 bytes from 192.168.1.223 (192.168.1.223): icmp_seq=3 ttl=128 time=0.378 ms ^C

ipa-adtrust-install

admin password:

WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing samba configuration.

Do you wish to continue? [no]: yes

Enable trusted domains support in slapi-nis? [no]: yes

NetBIOS domain name [EXC]:

Do you want to run the ipa-sidgen task? [no]: yes

ipa trust-add --type=ad XCLBR.TEST --admin Administrator --password --two-way=true

Realm name: XCLBR.TEST Domain NetBIOS name: XCLBR Domain Security Identifier: S-1-5-21-17222508-2060631821-777686506 Trust direction: Two-way trust Trust type: Active Directory domain Trust status: Established and verified

now I go to AD DC - AD Domains and Trusts - both outgoing and incoming trusts are there but when I try to validate the trust using admin@EXC.LOCAL account i get:

when i try to add admin@EXC.LOCAL user to remote users group via AD Administrative Center i receive this error

trying to add admin@EXC.LOCAL user via system properties to remote users produces:

local windows login using admin@EXC.LOCAL account to a XCLBR.TEST domain joined PC works

what am i doing wrong?

i also tried https://github.com/flo-renaud/freeipa.git -b gc-wip-flo with the same results

thanks!

[abbra]

This all sounds like you don't have correct Samba version installed from the COPR. As I said, that COPR repository contains prebuilt packages that can simply be installed and used. Please attach whatever logs you can produce out of IPA installation and a system in question, including list of packages installed. I am currently limited to just a mobile phone so cannot do much of analysis of it before next week.

[fixerivan]

[root@ipa ~]# dnf list installed | grep samba freeipa-client-samba.x86_64 4.9.0.dev202007171223+gitac1a24f12-0.fc32 @@commandline python3-samba.x86_64 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip samba.x86_64 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip samba-client.x86_64 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip samba-client-libs.x86_64 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip samba-common.noarch 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip samba-common-libs.x86_64 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip samba-common-tools.x86_64 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip samba-dc-libs.x86_64 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip samba-devel.x86_64 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip samba-libs.x86_64 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip samba-winbind.x86_64 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip samba-winbind-modules.x86_64 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip

[root@ipa ~]# dnf list installed | grep abbra 389-ds-base.x86_64 1.4.4.2-1.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip 389-ds-base-devel.x86_64 1.4.4.2-1.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip 389-ds-base-libs.x86_64 1.4.4.2-1.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip libsmbclient.x86_64 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip libwbclient.x86_64 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip python3-lib389.noarch 1.4.4.2-1.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip python3-samba.x86_64 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip samba.x86_64 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip samba-client.x86_64 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip samba-client-libs.x86_64 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip samba-common.noarch 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip samba-common-libs.x86_64 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip samba-common-tools.x86_64 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip samba-dc-libs.x86_64 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip samba-devel.x86_64 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip samba-libs.x86_64 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip samba-winbind.x86_64 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip samba-winbind-modules.x86_64 2:4.12.5-200.fc32 @copr:copr.fedorainfracloud.org:abbra:gc-wip

attached is the whole output of the dnf list installed command

all_installed.txt

as i am not sure which logs would help you I am attaching a zip of the whole /var/log/ folder

logs.zip

any other input i might provide to help diagnose the problem?

Thank you

[abbra]

A network trace between the IPA and AD DC would be great to see.

[fixerivan]

attached please find a zip file containing 3 pcap captures, all captured on AD DC using wireshark

trying_to_validate_trust_from_AD.pcap trying_to_add_ipa_admin_to_remote_desktop_users_group.pcap trying_to_add_ipa_admin_to_remote_users_via_system_properties.pcap

thank you

ad_freeipa_packet_captures.zip

[abbra]

@fixerivan could you please enable debugging level for samba on IPA master and re-do tests?

systemctl stop smb winbind
net conf setparm global loglevel 50
rm -f /var/log/samba/log.*
systemctl start smb winbind

I also need /etc/samba/samba.keytab to be able to decode the traffic between AD DC and Samba...

[fixerivan]

please see attached file, it contains the requested keytab, logs at the requested log level and pcap captures

debug.zip

thank you

[abbra]

Thanks. It seems your AD DC insisted on acquiring a service ticket to RPC/ipa.exc.local before contacting it. This should be an alias to cifs/ipa.exc.local. Looks like we lost that part of the code during refactoring.

Please run

ipa service-add-principal cifs/ipa.exc.local@EXC.LOCAL RPC/ipa.exc.local@EXC.LOCAL

and re-try again.

[fixerivan]

situation didn't improve after running the given command

logs and pcap files attached

while trying to add user to remote desktop users via AD Administrative Center the operation crashes the tool see screenshot:

debug2.zip

thank you

[abbra]

Thanks! One more issue I see is that LDAP server doesn't accept a ticket issued for ldap/ipa.exc.local/exc.local@EXC.LOCAL service. This one should already be an alias for LDAP principal (ldap/ipa.exc.local@EXC.LOCAL) and should be created as a part of the GC instance deployment:

2020-07-17T12:37:00Z DEBUG   [9/21]: add global catalog service principal aliases
2020-07-17T12:37:00Z DEBUG raw: service_add_principal('ldap/ipa.exc.local@EXC.LOCAL', ('ldap/ipa.exc.local/exc.local@EXC.LOCAL',), version='2.239')

Typically, a client would ask for a service ticket to that name and would get back a service ticket to the canonicalized service name. The client sends an LDAP BIND request with the service ticket. The latter somehow has three-component one. Sadly, krb5kdc logs don't show this ticket was issued. The closest I see is AD administrator asking for normal LDAP service ticket:

Jul 21 12:30:12 ipa.exc.local krb5kdc[1178](info): TGS_REQ (5 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), DEPRECATED:arcfour-hmac(23), DEPRECATED:a
rcfour-hmac-exp(24), UNSUPPORTED:(-135)}) 192.168.206.128: ISSUE: authtime 1595327412, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes2
56-cts-hmac-sha1-96(18)}, Administrator@XCLBR.TEST for ldap/ipa.exc.local@EXC.LOCAL

And we get LDAP BIND failing:

[21/Jul/2020:12:34:17.588335711 +0200] conn=150 fd=139 slot=139 connection from 192.168.206.128 to 192.168.206.143
[21/Jul/2020:12:34:17.588910399 +0200] conn=150 op=0 SRCH base="" scope=0 filter="(objectClass=*)" attrs="subschemaSubentry dsservicename namingContexts defaultnamingcon
text schemanamingcontext configurationnamingcontext rootdomainnamingcontext supportedControl supportedLDAPVersion supportedldappolicies supportedSASLMechanisms dnshostna
me ldapservicename servername supportedcapabilities"
[21/Jul/2020:12:34:17.589872891 +0200] conn=150 op=0 RESULT err=0 tag=101 nentries=1 etime=0.001189818
[21/Jul/2020:12:34:17.590922187 +0200] conn=150 op=1 BIND dn="" method=sasl version=3 mech=GSS-SPNEGO
[21/Jul/2020:12:34:17.592253293 +0200] conn=150 op=1 RESULT err=49 tag=97 nentries=0 etime=0.001471470 - SASL(-14): authorization failure:
[21/Jul/2020:12:34:17.593041258 +0200] conn=150 op=2 UNBIND
[21/Jul/2020:12:34:17.593081229 +0200] conn=150 op=2 fd=139 closed - U1

What Windows version are you using here?

It may well be that we need to add one more mapping rule to make sure three-component principals could be matched too if they are in aliases but I need to know what exactly did LDAP server see in the SASL mapping code. This could be found by enabling plugin tracing log level. See http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting and use nsslapd-errorlog-level: 16385 (1 | 16384).

[fixerivan]

as requested executed:

[root@ipa ~]# ldapmodify -x -D "cn=directory manager" -w .... dn: cn=config changetype: modify replace: nsslapd-errorlog-level nsslapd-errorlog-level: 16385 modifying entry "cn=config"

[root@ipa ~]# sync [root@ipa ~]# reboot

rebooted just to be sure changes were in-effect

logs and pcap files attached

debug3.zip

AD DC is running Windows Server 2019 with latest updates, AD functional level 2016, downloaded from here: https://www.microsoft.com/en-US/evalcenter/evaluate-windows-server-2019?filetype=ISO

thank you

[abbra]

Thanks! I think I know see where the problem is.

Can you please try to create an ID override for your AD administrator?

ipa idoverrideuser-add 'Default Trust View' Administrator@XCLBR.TEST

You don't need to add anything else, it just has to be able to map the incoming request by this user to an ID override entry in LDAP to accept the connection. If this works, then Administrator@XCLBR.TEST would be able to perform the operation.

[fixerivan]

thanks, executing on IPA:

[root@ipa ~]# kinit admin Password for admin@EXC.LOCAL: [root@ipa ~]# klist Ticket cache: KCM:0 Default principal: admin@EXC.LOCAL

Valid starting Expires Service principal 07/21/2020 22:05:03 07/22/2020 22:05:00 krbtgt/EXC.LOCAL@EXC.LOCAL

[root@ipa ~]# ipa idoverrideuser-add 'Default Trust View' Administrator@XCLBR.TEST

Added User ID override "Administrator@XCLBR.TEST"

Anchor to override: administrator@XCLBR.TEST

[root@ipa ~]# systemctl stop smb winbind [root@ipa ~]# net conf setparm global loglevel 50 [root@ipa ~]# rm -f /var/log/samba/log.* [root@ipa ~]# systemctl start smb winbind

trying to validate trust on AD DC results in the same error as before:

trying to add user to remote desktop users group produces the same error as before:

pcap captures + logs attached (sorry had to 7z them due to 10MB attachment limit)

debug4.zip

thank you

[abbra]

Thanks. The trace for the lookup shows everything is OK. The sequence of DCE RPC calls is following:

$ egrep '((in|out): struct|result )' log.smbd.lsasd.6 
                      result                   : DCERPC_BIND_ACK_RESULT_ACCEPTANCE (0)
          in: struct netr_LogonGetCapabilities
          out: struct netr_LogonGetCapabilities
              result                   : NT_STATUS_OK
          in: struct netr_GetForestTrustInformation
          out: struct netr_GetForestTrustInformation
              result                   : NT_STATUS_OK
          in: struct netr_ServerGetTrustInfo
          out: struct netr_ServerGetTrustInfo
              result                   : NT_STATUS_OK
                      result                   : DCERPC_BIND_ACK_RESULT_ACCEPTANCE (0)
          in: struct lsa_OpenPolicy2
          out: struct lsa_OpenPolicy2
              result                   : NT_STATUS_OK
          in: struct lsa_LookupNames3
          out: struct lsa_LookupNames3
              result                   : NT_STATUS_OK
          in: struct lsa_Close
          out: struct lsa_Close
              result                   : NT_STATUS_OK

And the network trace ends here after the last LSA Close call. So there might be something else with the Remote Desktop Users addition in the UI. At least, I can see AD DC searching LDAP (not Global Catalog) around the same time as it does LSA LookupNames3 call:

[21/Jul/2020:22:11:06.897752509 +0200] conn=132 op=4 SRCH base="CN=Administrator,cn=users,dc=exc,dc=local" scope=0 filter="(objectClass=*)" attrs="objectClass"
[21/Jul/2020:22:11:06.969516254 +0200] conn=132 op=4 RESULT err=0 tag=101 nentries=0 etime=0.118506164

It does not succeed, for obvious reasons, but shortly before that it succeeds with a Global Catalog search:

[21/Jul/2020:22:11:05.582892623 +0200] conn=5 op=7 SRCH base="CN=Administrator,cn=users,dc=exc,dc=local" scope=0 filter="(objectClass=*)" attrs=ALL
[21/Jul/2020:22:11:05.583362156 +0200] conn=5 op=7 RESULT err=0 tag=101 nentries=1 etime=0.000778655

Can you try the console tools instead? May be

net localgroup "Remote Desktop Users" exc.local\admin  /add

would help?

The trust validation is not necessary. Things work without it, it seems. However, it fails because on Samba side we attempt to respond to the validation request by trying to find XCLBR.TEST using NMB and fail due to nmbd not running. I am not sure why we do that, it needs more investigation in Samba code.

I am back to work next week, so I'll look at more detail into these issues then. Let's keep this issue open for a while.

[fixerivan]

interestingly that did work!

the AD Administrative Center clearly doesn't have the "right name":

but it is there!

what about adding the user to a domain group?

i am getting errors when i am trying to do for example:

PS C:\Users\Administrator> net group "Domain Users" admin@EXC.LOCAL /ADD /DOMAIN There is no such user: admin@EXC.LOCAL.

More help is available by typing NET HELPMSG 3755.

PS C:\Users\Administrator> net group "Domain Users" exc.local\admin /ADD /DOMAIN The syntax of this command is:

NET GROUP [groupname [/COMMENT:"text"]] [/DOMAIN] groupname {/ADD [/COMMENT:"text"] | /DELETE} [/DOMAIN] groupname username [...] {/ADD | /DELETE} [/DOMAIN]

when trying to actually use this user via RDP it seams to work only when i disable NLA in registry

Thanks

[abbra]

I don't think there is any support for RDP operations yet. It would need some protocol work that wasn't yet done. However, resolving SIDs to names should work if AD Administrative Center uses correct Windows APIs that lead to LSA LookupNames* family. Seeing logs and traces would help.Please cut off the previous logs though, they became too large, and also switch off the tracing in LDAP server errors log.

[abbra]

Note also that at least FreeRDP has had broken Kerberos implementation. I don't know about other RDP clients, the state used to be pretty bad Kerberos-wise. NTLM doesn't work for FreeIPA since we aren't generating NT and LM hashes so only Kerberos is supported.

[fixerivan]

interestingly when i try RDP with NLA against a domain joined PC which domain has trust with a pure samba DC (not IPA just samba) then RDP works even with NLA

[abbra]

Samba AD DC has support for NTLM, that explains it.

[fixerivan]

btw will NTLM come to IPA someday?

[fixerivan]

i always considered IPA to be some kind of superset integrating samba with other elements etc so when something works with samba ad dc I assumed it should work on IPA too

[abbra]

No, NTLM support was removed from FreeIPA 4.8+ and will not come back. RC4 cipher is insecure and it is not possible to make it secure at all, especially in FIPS environments.

There are only two use cases where RC4 is needed in SMB and DCE RPC protocols that cannot be avoided but both these cases can be enforced to run on top of AES-encrypted SMB3 channel. For the rest, switching to AES encryption schemes is the right way.

Of course, this means it is not possible to use out-of-domain workstations or non-Kerberos configurations without employing NEGOEX extensions supported on both sides but that is a separate story. It certainly doesn't need NTLM.

[abbra]

FreeIPA does not use Samba AD DC mode. It means it does not implement AD DC protocols. It implements minimal required functionality so that other AD DC implementations can see it as a DC in a separate forest for the trust purposes. But this is all, it cannot be treated as a full-featured Active Directory implementation and it is not focused on that. It uses Samba in a special mode that has nothing to do with Samba AD DC.

[fixerivan]

was reading a bit about groups in AD - it should be possible to add users from a trusted domain into a universal group in the AD domain, are you planning something like that? I tried it but it doesn't work at the moment, not sure why, anyway a feature like this would help a lot for use cases where users from IPA domain need to be used to access resources in the AD DC domain ... and local groups will not do the trick

thanks! btw sure lets continue debugging once you are back at work

[abbra]

@fixerivan we fixed Kerberos principal aliases now and with added ID override for AD Administrator my automated tests is now working just fine. I'm going to look at the trust validation separately but it should not be a problem -- you don't need to validate a trust if it wasn't established using a shared secret, it is done automatically for you already.

[abbra]

@fixerivan regarding universal groups, it is not possible to include members from trusted forests to universal groups. It is clearly stated here: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc755692(v=ws.10)?redirectedfrom=MSDN

The dialog window to add members only allows to choose from the same forest.