Instead of following whatever reference you’re using (and next time you post, it’s always critical to provide the reference so that others will know what you’ve done), you should instead use the AD/LDAP applet in YAST.
BTW - Even in the Windows world, except for the first couple years after Win2K3 AD was introduced, it’s also been advisable not to set up a local Domain using the “.local” suffix to avoid possible issues with certain 3rd party apps and services. If this is anything but a brand new Domain though, it may be a near impossible decision to tear down and re-build your AD (it’s incredibly difficult to try to change the name yourself, and creating an alias doesn’t solve the problem).
After you join the client to your AD, doublecheck your AD directory to verify your machine now exists and is recoginized as an “Other” machine.
There can be difficulties discovering the DC on your network, if that’s an issue I usually just add an appropriate Hosts file entry temporarily.
> Well, this particular domain has been up and running for more than 10
> years, it was started as an NT 4.0 domain once upon a time, no option
> there.
You mentioned that the domain is at 2003 level. I would try an older
openSUSE, to downgrade samba. Perhaps 11.4, which still has some
maintenance (Evergreen). If not, even older — just to find if it is
possible.
I bumped into the .local problem during some training. What I did was
change the AD name to something else (which crashes at least 30% of the
times). And from them on, I never created a .local domain. So I have
little experience with fighting the issue and keeping the AD name, I
gave up on it…
In fact I reported the issue on Bugzilla, requesting at least the
documentation warn of the issue, and possibly YaST.
Finally the issue is resolved, what was missing was name resolution within the AD domain, once I set the search domain name in network properties to the AD name, I got name resolution and then an AD join.
Just a closing note for other people that might walk this path.
Thanks to all the people that helped me resolve this issue.
On 2015-05-14 17:06, DavidLen wrote:
>
> Finally the issue is resolved, what was missing was name resolution
> within the AD domain, once I set the search domain name in network
> properties to the AD name, I got name resolution and then an AD join.
Search domain name? Wow. It is the first time I hear that thing having
any importance at all… we never end learning. :-o
> Just a closing note for other people that might walk this path.
>
> Thanks to all the people that helped me resolve this issue.
And to you for finding that important tidbit!
I wonder where would be the best place to document this… doc.opensuse.org, perhaps… :-?
Especially relevant for those of us accessing enterprise networks. Specifically, I have to use ‘Search Domains’ with domain name added for name resolution via a company VPN connection.
The ‘search domain’ name is entered in YAST’s ‘network settings’, on the hostname/DNS tab, I used the AD domain name xxxx.local in that field and the ‘domain name’ field.
Without it, I was able to ping the domain members’ IP addresses, but did not get name resolution.
I got a pointer from a member of the MSDN active directory forum, that got me to test for name resolution.
Anyway, now I can continue with .NET 5.0 and ‘visual studio code’ testing on Suse in the AD space, and that’s helpful.
Remember back in my original post I described making a Hosts file entry to point to the DC?
That should have addressed your name resolution problem. After joining, you can remove the Hosts file entry since as a member of the Domain you would be able to make full use of the AD DDNS. I wrote a long ago in a Windows forum about the importance of what I called “The troika” in AD… You need to have fully working DNS, DHCP and at least one DC to have a healthy AD. At any time if one or more isn’t working properly, you’ll have problems and when you first join a Domain you won’t be fully configured to use all three network services properly… yet.
Also, AD is AD when it comes to compatibility… The big break was from NT4 to AD (Win2K) and after that in some scenarios it might be important to know whether your AD is configured in “Mixed mode” (backwards NT4 compatibility) or not… But IMO not in your current situation.
You must login to your openSUSE box with an AD account.
Verify the group permissions of your AD account. You can do this by simply testing the account by logging into another box using the same AD account, but typically you already should have working AD User Groups and User accounts so an Admin typically just verifies that the new account is configured the same as other working accounts.
Joining the machine to the AD Domain only does a few things, but your current question doesn’t have anything to do with whether a machine is a member of the Domain, in fact technically depending on your AD security you can access AD resources from a machine that’s not joined to the Domain.
I think that I know what I did wrong, I kept the ‘auto login’ on, and that must have somehow bypassed the actual login into the AD from happening.
There is another gotcha (for me), the network management has to be ‘wicked’ or it’s impossible to set up the default search domain, but I prefer the network manager for a laptop, so, I gave up on joining the LT to the domain, and will use sneaker-net for data transfer.
NM still is probably better for laptops which typically connect using wireless. Don’t think it’s inferior to wicked, the two are just different.
And, switching to NM shouldn’t affect logging into AD, it’s a separate part of the login process.
Hint:
Probably the easiest way to switch between enabling and displaying auto-login is not through “User Management” but in YAST > Edit sysconfig.
Open that applet, then do a search for “login” which will take you to window with a simple enable/disable dropdown (enabling requires also specifying the auto login account).