Then that is very likely your problem, you should be using the DC as the nameserver and the DC should forward anything outside the AD DNS domain to the router.

You are having a Samba problem, which, from the sound of it, has nothing to do with Linux Mint.

Good idea, get one thing working correctly before moving on to another.

/etc/nsswitch.conf, as I modified it, then rebooted. I fixed DNS by modifying the host file. I found where I'd better do a PAM update (sudo pam-auth-update), after modifying the krb5 file. I did those things, my errors went away for samba join. Here are those 4 files. I tried changing case a bit. No dice. Do you still think it's my configuration of resolv.conf, or something else? I guess I might as well try to work on resolv.conf, just to see.

Attached Thumbnails

       

That would change the whole network. Is there another way?

Windows hosts work...

OK. I changed 2 files.

Attached Thumbnails

 

Joins with no problem. But won't allow me to log onto the network, like I also want. If it wasn't implied well enough, I don't care if I have extra benefits or not, but I want to be able to log on to the local system with ad credentials. What's wrong? When trying, it complains that it can't find the user. For any user in AD. Almost there, I think. Just have some issues, to resolve, because I don't know what's wrong. But I bet, it's smb.conf!

OK. Taking a break, while I wait for some answers. Randomly doing stuff will probably not work, I did all the logical things I know how, but don't want to do random stuff.

A question first, does the computer get its ipaddress via dhcp ? If it does, you need to find a way of updating the computers dns records in AD, Windows computers can do this automatically, Linux cannot. If you are setting the IP via dhcp it will probably be easier to ensure that it is always the same IP and then use samba-tool to add the PTR and A records to AD.

Next, /etc/nsswitch.conf, remove winbind from the 'shadow' lines, it should just be added to the 'passwd' & 'group' lines, it can cause some very strange errors the way you have it.

It isn't a good idea to use the '.local' TLD, that is reserved for Avahi and bonjour, so you either need to change it (probably impossible if the domain has been running for any length of time), or turn off Avahi.

Your smb.conf should enough to join the domain, but will probably need expanding later.
You are also using the 'autorid' idmap backend, which is okay, but it means that you cannot use 'winbind use default domain = yes'. Now this may be okay for your setup, but most people find it easier if they can use 'username' instead of 'DOMAIN\username' and you must use the latter with autorid. Perhaps the wikipage could be a bit more explicit on this point, I will go and change it.

As for the DNS, AD DC's are supposed to be authoritative for the DNS domain, all DC's, it is known as multi-master and the DNS records are stored in AD. It is very possible that your existing DNS server will not have all the required records and if it does have, they could be stale. The accepted best practice is to point all domain computers to a DC and then get the DC to forward anything outside the AD DNS domain, you appear to have been doing this in reverse.

Yes it does, according to the new standard. I was trying to create a new standard where all clients, unless for a special reason, like file sharing, get their IP from DHCP. Those that don't, get their IP from DCHCP, with a static reservation.

Before, all machines, even clients, except for special subnets, like guests, got their IP from DHCP reservation. I like the new standard better and I'd hate to break it for just that, unless it's absolutely neccessary. It is, showing up in AD computers, last I checked.

I'll do that, for sure, whoops! I was troubleshooting, trying to figure out how to make things work, so I'd added them. I'm sure the system uses shadow passwords and all that, by default.

They specifically told me in school it was "best practice" to use .local, for the end of the DC name. That's almost entirely why I did it. I'm sure I do use bonjour I'm pretty sure, on windows for printers. But anyway, here's how it went. When less experienced, I was going to use .net as the back name. There is no where at this time on the Internet, that .net is used with the specific domain I have. Unless it becomes the next google, I'm absolutely OK with having it blocked from my network, even if not specifically. It's unlikely, if they put something out by that domain name (smiley000.net), that I'd use it, except my network. I just fell back to .local to make it work, when fiddling with it.

It would take a lot of changes to fix it, and make it .net, so I'd prefer not to, but not if I break things. If I did change it, it's possible, but I'd need to unjoin everything from the domain, likely reinstalling the Linux on this mahcine, (and maybe the one I've been working on), and other than that, just rejoin everything. Then I'd need to take not of the whole AD structure, and DNS structure, and everything on the server, and totally re-enter it on the new server. If I have enough space, I can do this without tearing down the old one until I'm finished. They are just virtual machines on an antsle. I could do this, but if it's not really neccessary, I would like to avoid it for now.

The DNS, is only an internal DNS server. There's NO record of it on the Internet, and I can't afford to pay for it to be on the Internet. The only way to access the outside, or have it know about it, is smileynet000.ddns.net.

If it won't effect anything critical, and stuff like printers will still work, I can disable it. I haven't had any issues lately with ipad printing OK, which had to do with why bonjour was installed, I think. I don't know how to turn this service off (I know in general, but not specifically this one, like what configuration to redo).

Good. It's okay, as on linux, my prefferred way is <username@domainname>. But I'm ok if it MUST be <domainshortname\username>.

Yes, it's in reverse, and appears to be working. The problem does NOT seem to be that. Here's the why of why that is:

I am a small network. There are enough devices to need DNS. But I am very very small, and a one bedroom house. Thus running more than one DNS server, so far, makes no sense. I'd really like to be running bind for DNS, but for now, MS DNS works, since I couldn't figure out how to do that, I'll probably wait until I use Linux for domain resolution and THEN try to use bind for DNS, instead of that thing provided by default.

I just expect, some complete downtime of specifically the DNS server, while I fix some problems here and there. While the DNS is down, or if I redo it, I would like the Internet to still work. So, in the external resolvers for DNS, I have Open DNS, which I need to use somewhere, to make this network work, then I have google public dns, then I have last, my ISPs default DNS. In the router, I have it set to give the literal DNS server's IP as default, and, since it only allows 3, Open DNS as second. Those are what it literally gives. If I point with my computers to any router, they will point eventually to mainrouter, which gives the proper DNS, in turn. My AD server, might have a static IP from itself as well, and I know it has static DNS from it, pointing to the loopback of itself. I try not to have machines be static IPs from itself, but when required, I'm not afraid to do so. If I do that, it matches the IP in the DHCP reservations.

With this DNS setup, I almost never lose the Internet, even if I lose DNS, and therefore even AD. By the time that happens, it's likely that if everything is working, the usernames I want, are cached.

I'm aware now, about best practices, and because of what you are telling me, may have problems later I need to fix, a long time from now, but if I can just do things my way, if they work, great! These are probably all the quirks associated with my AD setup. Like I said, one way or another, it's working from the machine in which I type this, on Linux Mint, and the goal is to get it working on another - and document this time, immediately after.

So, I see why the samba way could be better, from all that I know of it. If it can not block file sharing, and the other way does, of course this way is better. i have it definately "joined", in the same sense that I have the other joined, when I did the "realm join". However, logon to users from either terminal or GUI, is not working. If I could just leave it the same, get a repeat of what I did, summarized, and then it logs on to the users, I'm happy for now, also assuming that sudoers works and when I'm an administrator I can sudo.

I'm almost to the point where I forget what I did, because it's taking a long time. I WILL have to try to reinstall and repeat, just to make sure I got it at this point. Please help me find the quickest path to that, and warn me of what I might experience if I don't change all those things, but if I don't have to right away, especially the .local thing, I don't want to. I'm also perfectly aware that for most servers, I'm running older things, like Mandriva, and I can't even rebuild them they are so old, but I don't want to rush to change those either - yet. I just want to make things work with the servers I have, and THEN likely I will want to go back right away, and make them better, unless it's just impossible to do. As much as I like tinkering, I just want to be able to get back to work on a machine right now. Programming and stuff like that.

I think I know what's wrong! It's the idmap backend, or whatever you call it! I want it to get the ids from AD, so I need to use "ad" as the back end! Now, next, please show me how to add to AD, using Windows GUI, for now, the IDs. If you can't do that with Windows GUI, please show me via samba command line. Almost there, I think. Thanks!

I guess not? And following about pam isnt making it work.

I completely messed up my filesystem, trying trial and error. I'm restoring and trying from scratch. I'm actually kind of getting it, or how it's suppossed to work, anyway.

1. First, we get DNS working. We modify nsswitch.conf
2. Then, we edit krb5.conf, and we tell it about the domain.
3. Then, we run pam-auth-config
4. After that, modify smb.conf, to AD configuration
5. Restart smbd
5. Modify nsswitch.conf one last time
6. Restart full samba services
7. Map the IDs
8. Join the domain

Will it work, if I directly do that?

The only error I ran into so far, as I followed this proccess, was the administrator, "Administrator", doesn't seem to have permission to access the machine accounts.

Here's my new smb.conf

Attached Thumbnails

   

Note: This time, I thought to use testparm. When I resolve this, it could be just what I needed.