Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Reid Bundonis

Pages: [1] 2 3 ... 8
1
Thanks for joining.  I hope the books are working out well for you.

I am not against private domains.  Just against .local domains.  .local is the Bonjour name space.  If you are doing anything where you are linked client devices to the server, you really want to avoid the use of .local because the system can too easily confuse server.local with server.lan.local. 

I fully understand the compliance issues.  But to protect yourself from potential issues, just make up a private domain for the LAN that does not conflict with Bonjour.  For example, cyborg.int or cyborg.lan.  By doing so, you will need to roll some DNS but now it is private DNS with no need for split horizon.  The server can be server.cyborg.int and this will allow OD to build properly as well as Kerberos.  Now, when binding your workstations, you will properly participate with kerberos and your mobile accounts or roaming accounts will be happy.

Hope this helps.

2
That is sounding a little backwards.  Are you on Sierra?  I am behind on my investigation with Sierra but I know a number of things have changed.

If I follow, you are defining groups and then setting SACLs on the groups.  Once this is done, you are creating users and adding them to the groups.  Is it the Workgroup group that is causing the issue or are you seeing the group flipping SACLs?

3
Apologies for the forum chaos.  I was getting hit with so many automated bots that I had to do something to stem the tide.  I will look at that again.

As for your project, have you looked at Okta?  We've been doing some Okta integration for O365 deployments where OD remains a requirement of the LAN.  Or what about JumpCloud?  If you are using OD for only user names and passwords, then there is not much that OD is offering that a cloud LDAP can not replace.  Might be worth looking into.

It is funny that you are having these debates in a 5 person location.  We have a customer that is over 200 users and everything is still all Apple based.  Xserves are still the file servers with a bunch of minis creeping in.  They are still on 10.6.8 if you can believe it.  As they say, it if ain't broke...  Anyway, we are at the point where OD needs repair and restructuring so we looked at all the options from OD to AD to cloud to hybrid solutions.  In the end, to stick with OD and use Okta in the middle seems to be the most affordable and flexible solution.  Time will tell if we got the right, but I guess we got the 10.6 deploy right.





4
Where are you seeing the self-signed?  Are you seeing this during device bind?  How are you binding? 

I can not say I've seen this yet.  I will run some tests this weekend and post back.




5
El Capitan Server - Foundation Services / Re: Multiple machine setup
« on: October 14, 2016, 12:19:05 AM »
My apologies.  Took some time off this week so I've been asleep at the wheel. 

Glad the books are helping.

Deciding where to place your services on a multi-server deployment is always a challenge.  However, if you are protecting the devices behind a firewall and only forwarding required ports, you should be generally safe.  (Obviously there is always a threat but your must weigh the benefits against the risks.)

Profile Manager is a product that could be great with a few additional features.  For example, there is no replication, backup, or redundancy built into the product.  Also, unless I've missed something in the new release, Profile Manager must run on a device running as an OD Master.  I've not tried to run it on a Replica but will give it a shot over the weekend.  Who knows, maybe it will work.

I will admit, I am frustrated with the fragility of OD of late.  There are many conditions where a reboot will simply destroy OD.  And this really makes Profile Manager angry.

I am working on the Sierra updates but I am behind :(  Really got deep into the Xsan chapter and then Sierra changed a bunch.  Ah, so goes software.




6
El Capitan Server - Foundation Services / Re: Typos - Chapter 2 pg 36 & 38
« on: September 16, 2016, 09:07:15 PM »
Thanks for the feedback.  I am glad it is helping.  That was my goal.


7
El Capitan Server - Foundation Services / Re: Typos - Chapter 2 pg 36 & 38
« on: September 09, 2016, 10:14:31 PM »
Thank you very much!  I will make the corrections and yes I am trying to get a Sierra version out by the end of the month.  Hope the book(s) have helped.  I am thinking of combining everything into one book.

Any time you see mistakes please let me know!

8
Added a new section on Password Policy and how to override global policy at the user level.  Imagine, no more locked out Directory Administrator accounts.

9
I think I see some of the issues that you may be facing. 

In test one, you have computer 2 run NSLookup.  But the DNS server it is talking to is the Airport at address 10.0.1.1.  You want it to ask the server at 10.0.1.221.  This is likely because your DHCP server is not delivering your server's IP address as the primary DNS server. 

In the case of the server's nslookup, it appears you have two A records defined.  You have the one for the LAN address and another for the public address.

Now the big question.  You are naming the server www.  Is this server going to be your web server?  Or, do you already have an external web server that you need to access from the LAN?

If you would like, this might be easier over the phone and with a remote session.  If you want, we can chat about it and I can demo the process rather quickly.  What time zone and availability do you have?

If you would like, we can schedule a time to

10
Welcome and thanks for reading.  I hope it is helpful.

So, you have a fixed address of the device at 10.0.1.160.  This is a LAN address, not a public address.  (This address should NOT be in your DHCP range.)  I will assume you are deploying your server behind a firewall/modem and not placing it directly on the Internet.

Ok, if this is the case, then you will want to employ split horizon DNS to ensure that LAN clients and WAN clients can access resources from the server using the same name.  Here is how this works in brief.  Let's say the server's name is server.pdjsf.com.  When devices join your LAN, they will get an IP address in the 10.0.1.x/x range.  They should also be served your server's IP address as the primary DNS server.  Thus, when a LAN client asks for resources on server.pdjsf.com the answer will come from your server and be 10.0.1.60.  Ah, but once those devices leave your environment, then will not have access to your LAN.  They must reference a public DNS server which will point server.pdjsf.com to your WAN's public IP address (and then you will use NAT or PAT forwarding to allowing specific packets into your network.

So I think the question becomes, where is your server sitting?  On the WAN or behind a firewall on the LAN?  If DNS service is showing a public address, then I would suspect you are deploying the server on a WAN address, not behind a firewall.

Let's start there and see if we can sort you out.


11
Took some time off for the holidays.  Still getting back into the swing of things. 

Advanced Services is available now.  Added a lot of content to system imaging.  The Web chapter is on schedule for January release.

12
El Capitan Server - Foundation Services / Re: Typo - page 43
« on: December 29, 2015, 05:27:44 PM »
Thanks again!  Any and all typos, please let me know.  It is amazing how many time I read through it and how many things I find something I missed.  That one is so obvious I am smacking myself in the head.

13
Thank you for the feedback and welcome to the forums!  I've toyed with the idea a number of times but always keep that content out.  One of the reasons is the one feature I want to work, option code 81, is not respected by Apple's implementation of bootpd.  I have a number of corporate clients that tie DNS and DHCP together and then Macs are always causing chaos with workflows based on names.

Since I've already started on some of this content, I will dust it off and consider it for the next update.  Thanks again.

14
Just posted updates for both the Foundation Services and Control and Collaboration.  Try again.  Maybe the new version will get past whatever is going on with the download.

15
El Capitan Server – Advanced Services / Now Available for Pre-Order!
« on: December 13, 2015, 08:21:40 AM »
Advanced Services is now available for pre-order.  Final release should be on December 28th.  Check it out: https://geo.itunes.apple.com/us/book/advanced-services/id1067614948?mt=13&at=10lLgZ

The Xsan chapter will need another month to complete.  Please read the description as the book will gain chapters after release.

Pages: [1] 2 3 ... 8