-
Notifications
You must be signed in to change notification settings - Fork 1
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
Comments
You need to use You'd need to install gc with ipa-adtrust-install. |
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) 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 systemctl stop firewalld ipa-server-install The IPA Master Server will be configured with: The CA will be configured with: BIND DNS server will be configured to serve IPA domain with: 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 ping xclbr.test 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 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: when i try to add [email protected] user to remote users group via AD Administrative Center i receive this error trying to add [email protected] user via system properties to remote users produces: 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! |
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. |
[root@ipa ~]# dnf list installed | grep samba [root@ipa ~]# dnf list installed | grep abbra attached is the whole output of the dnf list installed command as i am not sure which logs would help you I am attaching a zip of the whole /var/log/ folder any other input i might provide to help diagnose the problem? Thank you |
A network trace between the IPA and AD DC would be great to see. |
attached please find a zip file containing 3 pcap captures, all captured on AD DC using wireshark trying_to_validate_trust_from_AD.pcap thank you |
@fixerivan could you please enable debugging level for samba on IPA master and re-do tests?
I also need |
please see attached file, it contains the requested keytab, logs at the requested log level and pcap captures thank you |
Thanks. It seems your AD DC insisted on acquiring a service ticket to Please run
and re-try again. |
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: thank you |
Thanks! One more issue I see is that LDAP server doesn't accept a ticket issued for
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:
And we get LDAP BIND failing:
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 |
as requested executed: [root@ipa ~]# ldapmodify -x -D "cn=directory manager" -w .... [root@ipa ~]# sync rebooted just to be sure changes were in-effect logs and pcap files attached 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 |
Thanks! I think I know see where the problem is. Can you please try to create an ID override for your AD administrator?
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. |
thanks, executing on IPA: [root@ipa ~]# kinit admin Valid starting Expires Service principal [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 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) thank you |
Thanks. The trace for the lookup shows everything is OK. The sequence of DCE RPC calls is following:
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:
It does not succeed, for obvious reasons, but shortly before that it succeeds with a Global Catalog search:
Can you try the console tools instead? May be
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. |
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" [email protected] /ADD /DOMAIN More help is available by typing NET HELPMSG 3755. PS C:\Users\Administrator> net group "Domain Users" exc.local\admin /ADD /DOMAIN NET GROUP when trying to actually use this user via RDP it seams to work only when i disable NLA in registry Thanks |
I don't think there is any support for RDP operations yet. It would need some protocol work that wasn't yet done. |
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. |
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 |
Samba AD DC has support for NTLM, that explains it. |
btw will NTLM come to IPA someday? |
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 |
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. |
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. |
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 |
@fixerivan we fixed Kerberos principal aliases now and with added ID override for AD Administrator my automated tests is now working just fine. |
@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. |
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
The text was updated successfully, but these errors were encountered: