We have an environment with windows 2008 AD servers and opensuse 11.4 clients (just started testing on a new 12.3 system, but that isn’t connected to the network yet).
We have implemented AD authentication following Active Directory Authentication using LDAP - Gentoo Linux Wiki and this works ok. For every LNX system we added a systemuser to the AD and created the keytabs on the LNX system (/etc/krb5.keytab, permissions 600). A ticket is created using the bind-user as defined in /etc/ldap.conf
The ticket is renewed using cron every 10 hours, the ticket lifetime is a week.
The renewal of the ticket works correctly, until the ‘renew until’ date / time is reached; after that we get the following error:
system:/usr/lib/mit/bin # /usr/lib/mit/bin/kinit -R
kinit: Ticket expired while renewing credentials
I don’t understand why the tickets ‘renew until’ time isn’t updated after a renewal with kinit… The few articles on the internet regarding this all state that the ticket has to be complety destroyed & initialized at the ‘renew until’ time as far as I understood and 7 days is the max lifetime for a ticket. I don’t really like the idea of updating the tickets on all our LNX systems every week again
We don’t use samba in this setup (nor do we want to)… Any ideas?
On 09/27/2012 12:36 PM, hscheffers wrote:
>
> isn’t there anyone who uses this kind of setup or knows this problem?
i see you have had 82 views and not much help…
i can’t even begin to think about helping (since i know nothing about AD
or any windows server, or desktop)…
well…maybe this is helpful:
you might try IRC or mail list…the networking questions you ask are
generally of a higher technical nature than most (certainly not all)
folks here are familiar with…
On 09/27/2012 01:02 PM, dd@home.dk wrote:
> oh, by the way: what is an “LNX system”?
never mind, i found it (i just love Google!):
Definition: LNX System: The LNX System aims to be a well-engineered
Linux distribution, with a centralized CVS repository; structured and
flexible packaging; maintained and integrated subsystems;
pro-actively-secure and audited code; … LNXS 0.2.0 was released April
11, 2001.
On 09/27/2012 01:46 PM, hscheffers wrote:
> we use LNX here as shortcut for linux
LOL! oh really…wow, i guess if you make up ‘shortcuts’ you should
probably realize that not everyone knows your in office code…
hmmmmm Linux takes five strokes and LNX three, so you save two (or maybe
none if you type CapsLock lnx CapsLock), or one if you type Shift(and
hold it) lnx)
good enough, but i wonder do you also type WNDWS to save save two?
IMO the main reason why there might not be much of a response is that you went off the beaten path by following the Gentoo Wiki.
So, some questions are in order…
Have you much experience administering an AD or is that something you’d rather not touch? AD admins brag about how they use and configure GPOs. If you administer a larger company you may know something about Domain Trusts. You may monitor and configure machines remotely using AD. Do any of thoose things apply to you?
How did you select the Gentoo Wiki?
Is there some reason you want/need your non-Windows machines properly registered in the AD? Windows Security is fundamentally based on User authentication and authorization, machine authentication is optional. This is how and why a User can simply logon to their openSUSE with Domain credentials and immediately fully access Domain resources without further Admin configuration and involvement.
Do you have an idea exactly what you need and want from AD? If you want more than what I described in (3) above, there is software that will give you more AD capabilities normally only for Windows like Linux Host health monitoring, patch management, more.
Posting anew, I feel I probably should distill my prior post into something that’s framed in simpler terms…
Unless you had a special reason to follow that Gentoo Wiki, that’s a very inadvisable choice and hopefully any and all AD objects you created can be removed.
The steps you followed are based on some kind of idea that System Users on any machine should be integrated into AD. On the face of it, what a Gawd-awful idea, you don’t ever do that even on a Windows machine (although technically it can be done and has been done in a particular situation I won’t describe here).
As an AD admin, hopefully you should already know something about and have some experience with the differences and relationships between Local User Accounts and Domain User Accounts in a pure Windows network. Apply those same principles to your openSUSE, the main diff for a non-Windows box are
You won’t be able to manage, monitor or maintain the box using AD.
Hi TSU,
The (main) reason for following the Gentoo Wiki is that we don’t (want to) use samba in our environment. All the other options we found use at least part of the samba packages.
I am not a AD admin, just sysadmin for aix/linux. The integration of system users in the AD is partly done because of requirements our company has to fullfill.
What we mostly need from the AD is user authentication and group authorisation; groups are maintained in the AD and permissions for users granted by group-based sudo.
OK,
Now I’m seeing the big picture.
Still, for future AD decisions… particularly infrastructure design decisions I strongly advise finding yourself a sometime guru for those <big> decisions, the ones that will forever impact how you operate. Getting things setup initially is <very> important, after that you don’t always need guru-level knowledge to simply maintain what already exists.
Samba is not required in an AD network although it’s usually not excluded. If you use Windows Sharing, you will need SAMBA, it provides CIFS interoperability. You might be able to avoid using SAMBA on servers, but almost always SAMBA will be installed on client machines to access network shares on Windows Servers.
The other reason SAMBA is sometimes used on Servers is as an AD/LDAP authentication server (domain controller), but in a small network or if all clients can access your Windows DC properly, then it’s not necessary.
As for Users and Machines, here is a thumbnail on LDAP/AD architecture. I highly recommend you either read up on this further or gain some hands-on experience to more fully understand this…
AD/LDAP is <Network Security>, and it differs from <Local Security> in many ways, but here is a short list…
Local Security is scoped to the specific machine only. You should not extend further, it’s a serious security violation.
Local Security stores its security tokens on the machine it is securing. The OS will inherently trust and have easy access to the tokens this way.
Network Seurity is scoped to the company network. Typically nowadays often use an LDAP based model, and AD is an enhanced version of LDAP.
Proper Network Security stores its security <remotely> and not on a local machine. In AD, this is the Domain Controller (BTW - The PDC went out the window with NT4 Domains, today all DC are nearly equal).
Many benefits are enjoyed by moving Network Security off a local machine to a Server including
Better security because security tokens won’t be stored on a potential target host (unless cached)
Single Sign On - A User logs in once and immediately has access to <all> authorized resources
A Domain User Account can be used to logon to <any> machine in the Domain
Centralized administration of User Accounts
Possible centralized administration of machines (Full members of AD, typically non-Windows machines won’t without special software)
And, of course those basic benefits just listed will in turn enable other useful functions and tasks like
Remote administration of Network Assets
Ability to delegate permissions, tasks and more
So, why did I just describe the above?
Because it hits to the heart of why the Gentoo Wiki you’re following is so wrong… and IMO only after understanding that can you then start to understand the proper way to deploy Linux in an AD.
Instead of thinking of using System (Local) Users on the Network, you should be thinking of using Domain Users (Network) on local machines.
So,
After wiping out everything you did following the Gentoo Wiki (no exaggeration, you’ve got to do it completely before you do anything else),
Make your configurations in AD first
Decide if you need/want to create any special Domain User Groups or if the default User Group is OK (I prefer to keep my Linux Users separate with controlled access to Windows assets, but that’s just me. You need to decide what is best for your business). There are many articles and theories that guide creation of groups based on various characteristics like department, site, geographical location, access to special resources, more.
Create your Domain User Accounts if necessary. You can use existing accounts already being used to logon to Windows machines. Configure the accounts as members of appropriate Domain User Groups.
On openSUSE, open YAST and run the Windows Domain Membership applet. Follow the instructions, if your machine can contact a DC you should not experience any problems.
From then on, you should be able to logon to your openSUSE using the Domain User Account your created in (2) to access Domain Resources. Note that when the User wants to access Domain resources, the User <must> logon with a Domain User Account and <not> a local System Account. Also, if it hadn’t occurred to by now, it’s extremely useful to keep Domain User Account names <very> different than Local (System) Account names. Domain Admins who don’t take steps to make the names different will spend lots of time troubleshooting confused Users (not to mention your own inevitable confusion).
Optionally, but I do highly recommend… Using your ADSM, inspect the changes to your AD, you should see your Linux machine added as an unmanaged machine.
Finally… I’ll just raise the idea that if you’re using sudo, sudo is configurable. Most people think it’s only for temporarily granting Root permissions, but it can be configured to grant rights for any User Account. You should also consider that depending on how you implement sudo, it can conflict with Regulations that require User Accountability. User Accountability fundamentally ensures that there is a record that a particular Person (note I did not say User Account) can be identified as being tied to a particular activity. Any method that configures a shared User Account is almost certainly a violation.
We don’t have samba shares, our linux systems are used as servers
We don’t (want to) use SSO
Please explain this, as non-windows systems without special software are not full AD members, why the Gentoo Wiki is so wrong…
We use domain users on local machines. It is not possible to use a non AD account to login, unless you use the root login on console (secured by red envelope procedure)
Again: Please explain
What exactly does YAST use underneath the service to establish the AD configuration?
As far as I have understood… these includes (parts of) the samba package
We use sudo, sometimes to the command-level. All is based on group-access defined in our AD.
Shared Accounts is not perse a violation, there are tasks that can only be accomplished by shared accounts. Everything is audited, using the audit features on SuSE as wel as command-line logging per shell. (only a special version of ksh is available for login, also defined in the AD).
I understand from your reaction, that the gentoo way is not the way to go, but i don’t understand the reasons why… Could you please explain that?
Just because you say you “don’t have SAMBA shares” doesn’t mean you don’t need SAMBA. Anticipating this statement, I tried to describe how and when SAMBA is used on the client. Although it’s extremely unusual for Windows Networks to not configure any Network Shares, if that is your situation, so be it.
You may say you don’t want SSO, but all modern networking finds SSO desirable. SSO means that when you logon to a machine you are automatically authorized to access assets on the network ranging from network shares to access to the Internet to mail, more. Without SSO, you must configure your logon credentials for every connection to a network resource, and if you change your password you will have to re-configure everything all over again.
What I found objectionable was integrating local security with network security. They should be kept separate despite the attractiveness sometimes to be able to be God on another machine without being logged in as a Domain Admin (eg running a script on a remote machine). This is partly why early Windows has been obsoleted. The acceptable alternative to being a member of the Domain Admin group is to remote into a machine with sufficient permissions and execute the script or program locally (on the remote machine). Consequences of breaking this rule start at potential network compromise (compromise the right machine with God-like permissions on the Network and the exploit will now run on every machine immediately).
As I described, it depends on how you created your Domain User. You are relatively safe by using a Domain User Account created and maintained entirely using ADUG. If you “synchronize” Domain User Account with a Local System Account, then you’ve broken the partition between Local and Network Security. If the Domain User Account has been made to be more than it is by default then that’s dangerous unless you really know what you’re doing. Advanced Windows Admins may immediately identify the most obvious exception to this rule but I won’t discuss that in detail here which would muddy the waters. When talking about Linux machines, just know that even that exception can’t be applied here because whereas Windows Security is fundamentally based on User Security, Linux Security is fundamentally based on Machine security so the consequences of that practice is very different.
As I described, only way to fix your problem properly is to return to the state “before Gentoo Wiki.” Leaving anything behind is a YMMV. Maybe it’ll make a diff, maybe not. My advice is to not risk creating a “Frankenstein” which is a gumbo of this and that. Computing is hard enough getting things to work the right way without making your situation completely unique.
You can make your own decisions on using shared accounts, but I know that any hint of that violates HIPAA and SarBox in a big way. I do remember one Linux/Windows integration software does allow the use of sudo but only because it keeps its own “higher level” logs on how sudo is used. Normal logs <do not> sufficiently track who actually was doing what task if impersonation using sudo is used.
One last piece of advice, and I apply this to myself all the time…
Step One is to never stray from instructions when I’m learning a new technology. Oftentimes, i cannot see the purpose for why something is done until I’ve completed setting it up, debugging and getting it to work smoothly. And even then, sometimes I <really> have to use the technology for awhile exploring it before I can feel I really understand the reason why the technology works that way.
Step Two is questioning. Only after the technology is setup and running as it is originally designed can I start to question why it runs the way it does. If not setup correctly in the first place, then any questioning is fruitless, based on nothing real.
Step Three is what I hope for, to one day be able to “break the rules.” This cannot happen until enough experience has been accrued on a properly working system. If the system is running properly, <usually> there should not be any reason to break the rules, but there can always be that unique situation somewhere which because it’s atypical demands original thought. But, breaking the rules should never become habit, rules may be made to be broken but if they are good rules should almost never be broken.
