kinit problems

[hscheffers]

@tsu2

OK,
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.

We don’t have samba shares, our linux systems are used as servers

@tsu2

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

We don’t (want to) use SSO

@tsu2

• 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.

Please explain this, as non-windows systems without special software are not full AD members, why the Gentoo Wiki is so wrong…

@tsu2

Instead of thinking of using System (Local) Users on the Network, you should be thinking of using Domain Users (Network) on local machines.

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)

@tsu2

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),

Again: Please explain

@tsu2

3. 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.

What exactly does YAST use underneath the service to establish the AD configuration?

@tsu2

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.

As far as I have understood… these includes (parts of) the samba package

@tsu2

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.

HTH,
TSU

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?