Internal domain name same as external domain - DNS issues!!
-
@brianlittlejohn said:
With only 15 users, personally, I would spend a weekend and reset up my AD environment just to avoid issues in the future.
I would agree with @brianlittlejohn here. You had no AD at all prior too few days ago.
Just remove all the machines from the domain. Nuke your DC and start over.
-
@JaredBusch said:
@brianlittlejohn said:
With only 15 users, personally, I would spend a weekend and reset up my AD environment just to avoid issues in the future.
I would agree with @brianlittlejohn here. You had no AD at all prior too few days ago.
Just remove all the machines from the domain. Nuke your DC and start over.
As someone who does this a lot, even with more users than that, it's pretty simple.
I keep a few templates ready to go to deploy a base AD environment. Takes me ~3 minutes per end point to unjoin to the domain, about 2 hours to rebuild AD from template to completed environment, then ~3 minute per endpoint to rejoin. With that in mind, a 15 users environment, I could have it done in an afternoon while drinking beer.
Shit like this is easy as hell. Although I would be investigating the cost/benefit of having an AD environment for that few of users. Unless you have a case for it, Samba will do the job of authentication just fine. And a Samba domain is just as quick to deploy. Save quite a few bucks in the process. AD is great, I made my career around it, but it's not a need.
-
I've never used or worked with Samba so dont know anything about it. The AD I thought was great for them as they want to have more 'control' over users, add more security to the network and manage permissions on folders much better. I'm familiar with AD so thought it would suit them well.
The reason we named the domain name the same as their external domain is because a Microsoft technician advised me to do so if we wanted to Sync our Office365 tenant with the on-premise server.
I can easily nuke the DC and start over, but to re-configure the 15 computers and drag everything over to their new profile is easy, but frustrating to have to spend the extra time doing it as i've just done it for their new server!!!
-
@Our-Tech-Team said:
I've never used or worked with Samba so dont know anything about it. The AD I thought was great for them as they want to have more 'control' over users, add more security to the network and manage permissions on folders much better. I'm familiar with AD so thought it would suit them well.
Samba is just as much AD as Microsoft's DC is. Both are AD, just one is done from an open source project and one from Microsoft. It's not that Samba is not AD as well.
-
@Our-Tech-Team said:
The reason we named the domain name the same as their external domain is because a Microsoft technician advised me to do so if we wanted to Sync our Office365 tenant with the on-premise server.
Microsoft has been warning against this since the day AD was first released in 2000. It's, as far as I remember, the very first thing that they teach when starting hands on with AD in their courses and certs. Even in the NT4 era we were prepared to worry about it before upgrading to Windows 2000. This was a tech who actually worked for Microsoft and isn't aware of this? Something is fishy.
-
@Our-Tech-Team said:
... if we wanted to Sync our Office365 tenant with the on-premise server.
No such dependency.
-
@Our-Tech-Team said:
I've never used or worked with Samba so dont know anything about it. The AD I thought was great for them as they want to have more 'control' over users, add more security to the network and manage permissions on folders much better. I'm familiar with AD so thought it would suit them well.
The reason we named the domain name the same as their external domain is because a Microsoft technician advised me to do so if we wanted to Sync our Office365 tenant with the on-premise server.
I can easily nuke the DC and start over, but to re-configure the 15 computers and drag everything over to their new profile is easy, but frustrating to have to spend the extra time doing it as i've just done it for their new server!!!
You can use the AD migration tool if you spin up a new DC. Then it keeps all the SIDs for the users. Just join PC to new domain and it will keep using the profiles, no need to rebuild them. I just don't know if the setup for ADMT will take more time than just doing it manually for 15 users.
-
I havent worked with ADMT before but will look into it and if I'm capable of doing it and the time frames make sense, I'll go with it.....Otherwise when I have a spare weekend will probably nuke and start from scratch...Again if the main problem is ONLY that staff cant view their website internally then as far as I'm concerned this isnt a urgent problem that warrants immediate action. I'll create the DNS entries manually for the moment so hopefully it'll be okay for now...see the dns entired below, is this all I'll need to create (as well as the www record for the website)? Thanks again for your replies and responses.
-
@JaredBusch said:
@scottalanmiller said:
@JaredBusch said:
The only thing you could do is redo AD. Microsoft documentation uses ad.domain.com in their examples for this reason.
He had asked me about this offline and it appears, from our brief conversation, that the only impacts he is seeing is that he needs to manually put in external addresses into DNS (like www.mysite.com) so that it will resolve and the default domain points to the DC, not the website. As long as users are okay with that one URL not being usable and he's okay with the small amount of manual DNS entries, it looks like that is his only impact and he is fine not changing the domain at this point.
Unfortunate and not best practice, but it appears that the issues are minimal and his best option is to just remain with it as it is at this point. Not worthy modifying the domain now.
Correct, Really it is just that users will have to be trained to enter WWW in front of domain.com to get to the website. All links to the website will have to explicitly use www or it will fail.
You can also setup IIS on DCs to redirect domain.com to www.domain.com if you need to.
I'm glad we don't use the same one internally and externally. -
@Jason said:
@JaredBusch said:
@scottalanmiller said:
@JaredBusch said:
The only thing you could do is redo AD. Microsoft documentation uses ad.domain.com in their examples for this reason.
He had asked me about this offline and it appears, from our brief conversation, that the only impacts he is seeing is that he needs to manually put in external addresses into DNS (like www.mysite.com) so that it will resolve and the default domain points to the DC, not the website. As long as users are okay with that one URL not being usable and he's okay with the small amount of manual DNS entries, it looks like that is his only impact and he is fine not changing the domain at this point.
Unfortunate and not best practice, but it appears that the issues are minimal and his best option is to just remain with it as it is at this point. Not worthy modifying the domain now.
Correct, Really it is just that users will have to be trained to enter WWW in front of domain.com to get to the website. All links to the website will have to explicitly use www or it will fail.
You can also setup IIS on DCs to redirect domain.com to www.domain.com if you need to.
I'm glad we don't use the same one internally and externally.True, but that is just another role to deal with on the DC that does not need to be there.
-
@JaredBusch said:
@brianlittlejohn said:
With only 15 users, personally, I would spend a weekend and reset up my AD environment just to avoid issues in the future.
I would agree with @brianlittlejohn here. You had no AD at all prior too few days ago.
Just remove all the machines from the domain. Nuke your DC and start over.
HUH - I think I would bail on having a local DC at all, Since you have O365, I'd upgrade everyone to Windows 10 (if you can) and then use Azure AD.
What problems where you trying to solve by bringing in AD in the first place?
-
@Dashrender said:
@JaredBusch said:
@brianlittlejohn said:
With only 15 users, personally, I would spend a weekend and reset up my AD environment just to avoid issues in the future.
I would agree with @brianlittlejohn here. You had no AD at all prior too few days ago.
Just remove all the machines from the domain. Nuke your DC and start over.
HUH - I think I would bail on having a local DC at all, Since you have O365, I'd upgrade everyone to Windows 10 (if you can) and then use Azure AD.
What problems where you trying to solve by bringing in AD in the first place?
If you cannot upgrade to Windows 10 or cannot do so yet, you can still but AD on Azure, it just isn't Azure AD. Using AD on Azure is an awesome way to stop gap to get AD today and be ready to quickly phase out down the road.
-
@JaredBusch said:
@Jason said:
@JaredBusch said:
@scottalanmiller said:
@JaredBusch said:
The only thing you could do is redo AD. Microsoft documentation uses ad.domain.com in their examples for this reason.
He had asked me about this offline and it appears, from our brief conversation, that the only impacts he is seeing is that he needs to manually put in external addresses into DNS (like www.mysite.com) so that it will resolve and the default domain points to the DC, not the website. As long as users are okay with that one URL not being usable and he's okay with the small amount of manual DNS entries, it looks like that is his only impact and he is fine not changing the domain at this point.
Unfortunate and not best practice, but it appears that the issues are minimal and his best option is to just remain with it as it is at this point. Not worthy modifying the domain now.
Correct, Really it is just that users will have to be trained to enter WWW in front of domain.com to get to the website. All links to the website will have to explicitly use www or it will fail.
You can also setup IIS on DCs to redirect domain.com to www.domain.com if you need to.
I'm glad we don't use the same one internally and externally.True, but that is just another role to deal with on the DC that does not need to be there.
Yeah, I wouldn't want to deal with it but, I don't like doing split dns either.. just use ad.domain.com solves a lot of the issues.
-
@scottalanmiller said:
@Dashrender said:
@JaredBusch said:
@brianlittlejohn said:
With only 15 users, personally, I would spend a weekend and reset up my AD environment just to avoid issues in the future.
I would agree with @brianlittlejohn here. You had no AD at all prior too few days ago.
Just remove all the machines from the domain. Nuke your DC and start over.
HUH - I think I would bail on having a local DC at all, Since you have O365, I'd upgrade everyone to Windows 10 (if you can) and then use Azure AD.
What problems where you trying to solve by bringing in AD in the first place?
If you cannot upgrade to Windows 10 or cannot do so yet, you can still but AD on Azure, it just isn't Azure AD. Using AD on Azure is an awesome way to stop gap to get AD today and be ready to quickly phase out down the road.
That's true, didn't think of that, but there's expense if you spin up a VM, plus I have no idea how to get a secure connection back to your office.
-
@Dashrender said:
That's true, didn't think of that, but there's expense if you spin up a VM, plus I have no idea how to get a secure connection back to your office.
Yes, not free, but you can spin it down whenever.
Any normal VPN option works. IPSec, OpenVPN, Pertino, ZeroTier...
-
@scottalanmiller said:
@Our-Tech-Team said:
I've never used or worked with Samba so dont know anything about it. The AD I thought was great for them as they want to have more 'control' over users, add more security to the network and manage permissions on folders much better. I'm familiar with AD so thought it would suit them well.
Samba is just as much AD as Microsoft's DC is. Both are AD, just one is done from an open source project and one from Microsoft. It's not that Samba is not AD as well.
Samba is NOT AD. AD is a complete architecture including LDAP, DNS, and various other items. Samba functions in the old "Domain Controller" method, a single list of usernames and passwords in which to authenticate against. In AD, there is no DC, there are Global Catalogs. Domain controller emulation, a part of the FSMO roles, is not necessary to run and is only there for backwards compatibility. In an AD environment, Samba can function as a PDC emulator, but it cannot hold other GC roles, so it becomes kind of useless.
To the end user, they are functionally the same. To the admin, they are very different.
-
@PSX_Defector said:
Samba is NOT AD. AD is a complete architecture including LDAP, DNS, and various other items. Samba functions in the old "Domain Controller" method, a single list of usernames and passwords in which to authenticate against. In AD, there is no DC, there are Global Catalogs. Domain controller emulation, a part of the FSMO roles, is not necessary to run and is only there for backwards compatibility. In an AD environment, Samba can function as a PDC emulator, but it cannot hold other GC roles, so it becomes kind of useless.
To the end user, they are functionally the same. To the admin, they are very different.
Are you thinking of Samba from long ago before AD was implemented? Samba used to be that way, but Windows used to be that way too. Samba is full AD and has been for quite a long time now. LDAP, Kerberos, DNS, all there. (DNS is handled externally, of course, just like on Windows.)
-
Here is information on how to get the FSMO roles moved between Samba servers.
https://wiki.samba.org/index.php/Transfering_/_seizing_FSMO_roles
I assure you, Samba is full AD.
-
@scottalanmiller said:
@PSX_Defector said:
Samba is NOT AD. AD is a complete architecture including LDAP, DNS, and various other items. Samba functions in the old "Domain Controller" method, a single list of usernames and passwords in which to authenticate against. In AD, there is no DC, there are Global Catalogs. Domain controller emulation, a part of the FSMO roles, is not necessary to run and is only there for backwards compatibility. In an AD environment, Samba can function as a PDC emulator, but it cannot hold other GC roles, so it becomes kind of useless.
To the end user, they are functionally the same. To the admin, they are very different.
Are you thinking of Samba from long ago before AD was implemented? Samba used to be that way, but Windows used to be that way too. Samba is full AD and has been for quite a long time now. LDAP, Kerberos, DNS, all there. (DNS is handled externally, of course, just like on Windows.)
Yes, I know what 4 introduced, but it's still not functionally AD. It can be put in as a member controller, but god help you if you try to move FSMO roles to it. At best, it can be considered pseudo-Active Directory. If you only have Samba controllers, hell it might work. Never tried it by itself with multiple controllers functioning like AD. Although I can't imagine it is that indifferent than standard LDAP. I just know better than to mix the types together.
-
@PSX_Defector said:
If you only have Samba controllers, hell it might work.
that's the normal way to use it. Mixing it in would just be weird. Lots of companies run on just it, it works great from what I hear. I've never heard of a shop that had issues after moving to it. It's full AD with all the bells and whistles. You can even manage it from Windows and GPOs work great too.
