Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gc-wip trying to reproduce demos from samba XP #36

Open
fixerivan opened this issue Jul 16, 2020 · 27 comments
Open

gc-wip trying to reproduce demos from samba XP #36

fixerivan opened this issue Jul 16, 2020 · 27 comments

Comments

@fixerivan
Copy link

fixerivan commented Jul 16, 2020

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

image

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

image

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
Copy link
Owner

abbra commented Jul 16, 2020

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
Copy link
Author

fixerivan commented Jul 16, 2020

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 [email protected] account i get:

image

when i try to add [email protected] user to remote users group via AD Administrative Center i receive this error

image

trying to add [email protected] user via system properties to remote users produces:

image

local windows login using [email protected] 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
Copy link
Owner

abbra commented Jul 17, 2020

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
Copy link
Author

fixerivan commented Jul 17, 2020

[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
Copy link
Owner

abbra commented Jul 18, 2020

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

@fixerivan
Copy link
Author

fixerivan commented Jul 18, 2020

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
Copy link
Owner

abbra commented Jul 20, 2020

@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
Copy link
Author

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

debug.zip

thank you

@abbra
Copy link
Owner

abbra commented Jul 21, 2020

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/[email protected] RPC/[email protected]

and re-try again.

@fixerivan
Copy link
Author

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:

image

debug2.zip

thank you

@abbra
Copy link
Owner

abbra commented Jul 21, 2020

Thanks! One more issue I see is that LDAP server doesn't accept a ticket issued for ldap/ipa.exc.local/[email protected] service. This one should already be an alias for LDAP principal (ldap/[email protected]) 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/[email protected]', ('ldap/ipa.exc.local/[email protected]',), 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)}, [email protected] for ldap/[email protected]

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
Copy link
Author

fixerivan commented Jul 21, 2020

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
Copy link
Owner

abbra commented Jul 21, 2020

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' [email protected]

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 [email protected] would be able to perform the operation.

@fixerivan
Copy link
Author

thanks, executing on IPA:

[root@ipa ~]# kinit admin
Password for [email protected]:
[root@ipa ~]# klist
Ticket cache: KCM:0
Default principal: [email protected]

Valid starting Expires Service principal
07/21/2020 22:05:03 07/22/2020 22:05:00 krbtgt/[email protected]

[root@ipa ~]# ipa idoverrideuser-add 'Default Trust View' [email protected]

Added User ID override "[email protected]"

Anchor to override: [email protected]

[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:

image

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

image

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

debug4.zip

thank you

@abbra
Copy link
Owner

abbra commented Jul 21, 2020

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
Copy link
Author

interestingly that did work!

image

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

image

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" [email protected] /ADD /DOMAIN
There is no such user: [email protected].

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
Copy link
Owner

abbra commented Jul 22, 2020

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
Copy link
Owner

abbra commented Jul 22, 2020

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
Copy link
Author

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
Copy link
Owner

abbra commented Jul 22, 2020

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

@fixerivan
Copy link
Author

btw will NTLM come to IPA someday?

@fixerivan
Copy link
Author

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
Copy link
Owner

abbra commented Jul 22, 2020

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
Copy link
Owner

abbra commented Jul 22, 2020

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
Copy link
Author

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
Copy link
Owner

abbra commented Jul 30, 2020

@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
Copy link
Owner

abbra commented Jul 30, 2020

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants