All posts by A.G.

Nexus 5: Lollipop OTA, keep root, keep data :)

Say you have a towel (or other exploit) rooted Nexus 5, Android 4.4.4, with locked boot loader, careful setup and data. Lollipop OTA knocks at the door. You want it. You realize: I WILL LOOSE ROOT. You could use chainfire’s auto root. You realize: I WILL LOOSE DATA. Damned.

Disclaimer: Lolli colors might make your kittens escape into microwave oven. Check. Your business. Not mine.

Ok, so this is how to go:

  1. Unlock your boot loader from the INSIDE. https://play.google.com/store/apps/details?id=net.segv11.bootunlocker&hl=en
  2. Install the OTA update. Takes a while. Brings colors. And, er, bugs. Facebook app to hell. 100% weird.
  3. Enable USB Debugging. Oh my gosh! http://www.kingoapp.com/root-tutorials/how-to-enable-usb-debugging-mode-on-android-5-lollipop.htm
  4. Reboot 2 times. Bugs getting better (aha!)
  5. Download CF-Auto-Root, follow instructions. http://autoroot.chainfire.eu/#fastboot (I’ve modified the script a bit, because I’m sort of paranoid. Commented out the line that unlocks the boot loader. But should be fine without doing so, as it’s already unlocked)
  6. Optional/recommended: relock your boot loader for safety.

Done. Have fun. Facebook fine after un- and reinstalling.

Windows 8.1 and Macintosh: Remote Desktop Connection

After upgrading Windows to 8.1 remote connections from my Macintosh using Remote Desktop Connection seized to function. The symptom is, when trying to connect, it complains as follows: “Remote Desktop Connection cannot verify the identity of the computer that you want to connect to”.

There are two workarounds for this.

No. 1: Install the new Client from the Mac AppStore. It works, but I don’t like it because of two annoying flaws. First of all, it opens my present .rdp-Files but doesn’t understand them and throws an error. Second, if it’s in fullscreen mode, unlike with the old client, the Macintosh Dock is not accessible anymore.

No. 2: Set two group policies, as described here by VMware:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2059786

This can be done locally or on the Active Directory Domain Controller (I’m successfully using the latter method). According to Microsoft, this is less secure, in theory.

built myself new PC

I’ve finally made the decision to replace my good old Dell Vostro 200 MT with something new. I decided to use an ITX case I still owned, threw out the Atom D2550 board and mounted an MSI Haswell board inside. CPU is a Core i7 4770S. I’ve added 16GB RAM, a 128GB SSD. A 2TB hard drive was already inside. OS is Windows 8, joined to the now productive Samba 4 AD domain.

It nicely runs Virtualbox VMs, but apart from this I haven’t had the time yet to get the CPU to its limits. I plan to challenge its computation power by producing a mandelbulder animation (maybe using even more CPU cores on other machines I own, like the Dell, the Core i3 550 Server and maybe my Core i7 750 web server. So that’s 22 threads altogether.). Creating some new sound pieces would also be nice with it.

I’m quite happy with that small thing. Heat does not seem to be a big issue, it’s fairly quiet, and Linux has shown me a bus bandwidth of 16GB/s (hdparm –tT /dev/sda). The onboard graphics (called Intel HD 4000) allows three displays attached and performs greatly decoding H264.

possible Pitfall of Samba 4 AD Deployments

Once a new Active Directory Domain has been provisioned using Samba 4, it seems at least difficult to change the IP address of its Domain Controller. Samba 4 in AD DC mode does not automatically change its own address. Looking at the DNS data using Apache Directory Studio, I found the Resource Records to be encoded binary. Although still readable, Apache DS didn’t easily let me change them (one could do it, but it’s cumbersome).

I haven’t yet profoundly studied samba-tool, so there might in theory be a way to solve this kind of situation. For now, I have given up that testing domain, as in the meanwhile it had suffered from some challenges anyway, and nothing really depends on it. Provisioned again, joined a client, and I can continue my research on a new setup. Easy.

Conclusion: The question what to do when migrating your address scheme, say from using a CLASS-C net below 192.168.0.0/16 to something bigger below 10.0.0.0/8, seems quite important. Apart from the mere possibility to switch over with an S4 DC at all, it’s sensitivity for address scheme changes makes such migrations a lot more challenging. Might be good advise to migrate address wise first, if needed, before switching to production with an S4 DC.

Windows 8 joining Samba domains, and which ones it just fails to join (those with dots in their names)

TO SAY AS OF MAI 2015

There are two way to get Windows 8 into a NETBIOS/samba3 dot style domain.

  1. Join Windows 7 and upgrade to 8/8.1 – works perfectly.

2a. second method is basically tampering with DNS name resolution temporarily in the network interface settings. There’s a link down in the comments. I can confirm Havrlas method works fine. 🙂 thanks again

2b. for now just an idea, but what about just stopping the DNS-Client in Computer/Manage/Services … haven’t tried that yet, but I will on the next occasion, if it comes before migrating to S4AD.

EDITED JULY 16, 2013

former post name: Windows 8 failing to join certain Samba domains

Usually, Windows 8 can indeed easily be integrated into classic Samba environments, say improved NT4 domains. And, yes, Microsoft has indeed dropped native NT4 support and deliberately developed some sort of compatibility mode to support Samba, it seems.

To enable Samba 3 domain membership, three registry keys have to be changed by the user, whereof we already know two from Windows Seven. The first one, named DomainCompatibilityMode, is quite obvious by it’s name, though its name doesn’t exactly imply how that works. The second one, DNSNameResolutionRequired, is to a lesser degree obscure, but still, its name doesn’t tell us for what exactly DNS names do or do not need to be resolved (sure, DNS is needed to find AD DCs, but that can’t be the whole truth about this regkey). The third one is new since Windows 8, and it’s a rather rude one. It’s a change in the Workstation Service dependencies which results in SMB2 support being disabled as a whole. This requirement results from shortcomings in the SMB2 support in Samba 3.6. While SMB2 support in Samba is considered helpful for Windows 7, it is not compatible to Windows 8’s more advanced implementation. This is at least the case when connecting to a DC, resulting in two options, which are to turn off SMB2 either on the server side (“max protocol = nt1”) or on the client side via the described registry key change.

Continue reading Windows 8 joining Samba domains, and which ones it just fails to join (those with dots in their names)

Samba 4 experiments

Finally there’s is a great milestone reached in the world of Open Source IT business infrastructure: Samba 4 has achieved stable state and provides us with a free (as beer, and liberal) Active Directory implementation, which, properly packaged and deployed to a suitable environment, seems to work out of the box.

Of course it took a while to figure out how to run such a bleeding edge development on stable Debian. SerNet has done great work in this area. Basically, I use their Debian packages, but rather than installing the iso file of the appliance, I only use their packages, together with recompiled bind9 from sid (or wheezy? I’m sorry, I forgot. Needed the P3 packaging, and dlzones worked fine). The main reason is, I want to run this inside a Xen based (shell only) environment and be ready for normal Debian network based provisioning.

Integration into given LAN environments is another issue. You have to make your central DNS refer to the DC’s DNS, and there are multiple ways to do that. One of my objectives is, to figure out what can be considered best practice here. Getting ready for real life also covers to figure out replication, backup strategies, consistent cross server ID mapping, authentication on the shell level, consistent file access (permissions/ACLs, see also here) across smb and ssh access and last but not least deployment and migration strategies including architectural changes to be done to the given environment.

Test-Installations of Windows are easy to get using VirtualBox. I recommend to setup a basic windows installation with the Default User modified to your preferences (Desktop setup and such trivial things), needed Tools readily installed (like alternative browser, AD admin tools, sysinternals), the vm “syspreped” and then exported. Don’t add to much, as you can do this by rolling out Software using GPOs and a repackager (like Scalable Smart Packager Community Edition, be ready to register).

So, there are some things left to do, but for now, I’m really amazed and I’m taking my hat off to the samba guys, including SerNet.

weird Samba 3.6.10 behavior with ACL masks

I have no idea what’s going on. Some people seem to mention this behavior, but never there is any solution around. It’s only few people, so it looks like a configuration issue, and either it’s really rare or so common that I’m the last who didn’t get it yet. It’s as follows.

I have an experimental setup with a Samba 4 AD instance as Domain controller. The VM that demonstrates the bug is a samba 3.6.10 member server. Both are based on SerNet‘s builds (enterprisesamba and packages from the SerNet Samba 4 Appliance). Everything’s hosted on a Xen machine and made with debian squeeze as the base OS.

Rainbow Shield Bugs on Jatropha,
Ton Rulkens, Mozambique

Inside one share, I have a directory with some ACLs set, with the mask and default mask set to rwx. If I’m now creating a file using the shell, the file’s ACL mask becomes rw which is just correct. If I’m doing the same with samba, the mask will be rwx which is just plain wrong as the file would be executable like this.

I’ve tried many more or less random things like s-flags, samba parameters (inherit acls has no effect, it seems) and googled as described above, but this thing’s going consistently wrong.

Anybody around who knows more or is stunned like I am? Well, I didn’t expect to run into this issue, really not.

I’m giving back!

Whoever helps me to find an answer or even a fix can get some of my knowledge in the form of code: I offer a complete setup for Samba 4 and 3.6 experiments with Debian Squeeze. It incudes a debian packages source with all you need for such a (virtual) environment of this kind, such as an updated bind9 build and integratable S4 packages and a time saving xen-tools role script, which installs a DomU with these package sources, adding SerNet’s 3.6 (remote) sources as well, many often needed standard packages readily installed, /etc/hosts file adapted to the LAN environment, ethtools, NFS4 mounted from DomU (for easy data exchange between VMs, filesystem ACLs readily setup, and an A record added to a DNS zone file on the host system. So that’s all those repeated tasks after xen-create-image that usually take about 30 to 60 minutes every time to turn the installation into a comfortable, accessible and well integrated VM ready to dig into Samba’s Active Directory implementation details, and even taking steps towards a future production environment on a clean debian foundation (we’re not that far though, in my opinion).

Using this role and some more files in /etc/xen-tools/skel, it takes me 15 minutes for a S4-AD DC and a member server provisioned and up running, ready to join a Windows client and access with native AD management tools.