Video Screencast Help

Adding a group to a security role (Altiris 7.1)

Created: 08 Feb 2011 • Updated: 24 Mar 2011 | 18 comments
This issue has been solved. See solution.

Hi all:

I'm diving into the security configuration in the Altiris 7.1 Beta and I cannot find how to include an AD group into a security role.

I can include single users, but I cannot imagine how to include an AD group.

Is there anyone who can help me with this?

 

Thanks:

      Falquian

Comments 18 CommentsJump to latest comment

jpn010@tower's picture

In looking at my 7.0 system, it is exactly the same as in NS6 and groups (not users) are selected by default.  Is it changed in 7.1?

Joe

Falquian's picture

Hi, Joe:

Thanks for your answer...but I'm afraid that the security has changed significatively in 7.1

Both in 6.x and in 7.0, you can check that some local groups have been created in the Altiris servers, related to the Altiris/Symantec security roles.

In version 7.1 I cannot find those local groups in the Altiris server.

In version 7.1 you have to work with "credentials", "accounts" and "roles" inside the console...but I cannot find how to add an Active Directory group into a credential/account/role. I can add individual users, but not groups. And this is going to be a pain to manage once we go for production :(

I've read the SMP 7.1 User Guide, and in the chapter 4: configuring security, I cannot find how to add an AD group.

In that chapter, in page 61, they describe the "Select Users or Groups dialog box", but I'm not able to see this dialog.

 

Regards:

          Falquian

Kind regards:

     Falquian

If this post is useful to you, remember to mark it as a solution ;)

powellbc's picture

It has in fact changed. You now add accounts to the NS, and from there assign credentials (which for most will be AD based accounts).

Falquian's picture

Do you mind explaining the steps you must follow (or point me to an article/document where this steps are written) in order to configure the security?

I'm quite lost just following the instructions in the SMP User guide :(

 

Thanks:

        Falquian

Kind regards:

     Falquian

If this post is useful to you, remember to mark it as a solution ;)

tkiehl06's picture

Not sure if this is what you are looking for, but in order to accomplish this you should try the following steps.

In the Symantec Management Console, go to Security, Notification Server, Account Management.

Select the Accounts Menu, click Add. Give the Account a relevant name. Once it is created, its properties window will open to the right. Select Add Credential. Type in the Domain Name of the User or Group.

Give the Account a Full Name, Enable, and Save. You can then add it to a Role to grant it access to whichever parts of the SMC you like.

Hopefully this will help at least point you in the right direction.

jpn010@tower's picture

I tried this and wasn't able to get it to work.  Does it work with nested groups (GroupA contains Groups 1, 2 and 3.  Add GroupA to a security role.  User in Group 2 is not able to login)?

Joe

tkiehl06's picture

It looks like you can only have one WIndows Credential per Account. But Accounts can be Members of multiple Roles. Roles can be members of multiple other Roles, but not a member of itself. I am still trying to wrap my head around how the security works as well and have already run into some really frustrating problems.

Falquian's picture

Thanks for your replies.

It seems I'm not the only one having this "issue".

I'll keep this post updated with my findings related to this, so hopefully this will help others :D

 

I installed Altiris 7.1 final on my lab, and security was one of my things in the "to do" list, as you can imagine.

On this Altiris 7.1 server, I can inlude AD groups to an account without any problem (this was something that I couldn't get to work in the beta)

The only precaution you must have is: if you are trying to add a local group (from the server where you have SMP installed), you must include just the name of the group. For example: "Altiris Admin". If you include the server name, as in "<server>/Altiris Admin", you'll get an error.

Once you type the name of the local group, and "Save Changes", the console will add the name of the server automatically.

I really miss something more "sophisticated" as in version 6.0, where you could select the group from a list, instead of typing the group's name.

The problem is that, even though I included the group to the credential, and the credential is member of the Symantec administrators role, users included in that local group are not able to even connect to the console.

I'll keep inventigating on this. I think this can be related to permissions at a Windows level (or may be at IIS).

 

Regards:

      Falquian

Kind regards:

     Falquian

If this post is useful to you, remember to mark it as a solution ;)

Falquian's picture

Hi:

I created an account for just a user (not a group), and added that account to the Symantec Administrator role, and now that user is able to connect to the SMP console.

It seems that the link between the users and the groups is not working properly.

 

Regards:

         Falquian

Kind regards:

     Falquian

If this post is useful to you, remember to mark it as a solution ;)

Pascal KOTTE's picture

Security in 7.1 is more simple in fact:

  • go to the Active directory connector
  • activate the addition "role" import item, and list the domain group you want to import. (ie if you prefix domain, more simple to filter: app-altiris-operators, app-altiris-admins,app-altiris-reporters,etc...)
  • This will create directly the "role" as a CMDB item, under the Altiris security settings. Members, will create automatically also, members those roles.
  • Add your "imported" roles group items into the appropriate predefined groups (Altiris Administrators, Workers level 2, etc...), one more as needed. You can also custom rights, of course.

That's it !

Hum any body can refresh me the good article or documentation describing the predefined rights for existing roles ? Don't get it again, all the same I read already something similar...

The caveat this new way: You must force an update import when adding a new member one your domain group, instead immediat availability like it was 7.0 & 6.0.

But the good news, you can migrate roles other servers more easily, without needing to recreate your roles on local group, and manually rebuild same SID, like it was with 6.0 & 7.0 :)

Please mark it a solution if it is, or ask me more if needed. Enjoy 7.1 !

~Pascal @ Kotte.net~ Do you speak French? Et utilisez Altiris: venez nous rejoindre sur le GUASF

Falquian's picture

Hi, Pascal.

Thanks a lot for providing this information.

I'm trying to get it to work, but I'm facing a couple of problems:

1.- If I try to run the import from the local server where the SMP is installed on, I get the following warning in the logs:

Source: Altiris.DirectoryServices.DirectoryExport.LDAPExporter

Description: While getting RootDSE <servername> System.Runtime.InteropServices.COMException caught in GetRootDSE. Reason: The server is not operational.

. This is expected when grouping by 'User Groups'.

 

(I'm running the task with the windows credentials of a local administrator)

 

2.- If I try to import Roles and accounts from the domain, I can not import only AD groups. It imports also users.

Is there any way of importing just user groups?

 

Can you help me with this?

Where can I get documentation about this feature (importing Accounts and roles from AD)? In the SMP User Guide I'm reading, there is no menction to this feature

 

Thanks a lot, Pascal:

        Falquian

Kind regards:

     Falquian

If this post is useful to you, remember to mark it as a solution ;)

Pascal KOTTE's picture

By design the users members a "role" groups are imported as well. It is the life reason of this Altiris AD connector. So if the group you want to import does not match/fit the peoples you want inside, to assign altiris roles: you must create additionnal groups into AD, for your specific Altiris roles, and put the good "members" inside the AD groups.

The target is to manage Altiris Rights directly using AD, adding or removing people inside those "Roles group" (by the way, can be easily delegated a RH non IT people, like simple updating membership from outlook).

Regarding your AD connector import: You must use a credential having "reading" rights into the Active Directy LDAP. A normal user, usually used as "application credential", having full rights the Altiris server + SQL DB, but normal user into AD (Also often called the "Altiris service account").

Hope this can help you.

~Pascal @ Kotte.net~ Do you speak French? Et utilisez Altiris: venez nous rejoindre sur le GUASF

SOLUTION
Falquian's picture

Thanks for your suggestions, Pascal.

I'm still thinking in the "6.0" way of using security.

I still cannot understand why I cannot create an Symantec Account that is linked to a AD group, instead of having to create as many Symantec Accounts as users that are members of that AD Group. I think this would be very straight forward.

 

I could, finally import an AD group (and all the members of that group) and it's simply crazy. The AD connector has imported all the users that are members of that group (I guess that they are close to 1.000 users in that group), and more than 20 AD groups, that are members of the initial AD group.

I would suggest showing a confimation dialog  when importing from AD will have such a big impact.

 

BTW: Is there any way of deleting a bunch of users? From the console, I cannot select some users to delete them in one step, I must go one by one.

Regards:

        Falquian

Kind regards:

     Falquian

If this post is useful to you, remember to mark it as a solution ;)

james_g's picture

i would like to understand if AD references being imported and then used for authentication is a feature or a bug ?

is there a roadmap to deliver Single SIgn On which will be capable of background checking a CMDB reference for a authenticated user ?

or will the authentication be processed by the CMDB with some kind of validation for password with an AD ?

managing two object entries if using an AD environment (which most people are) is simply backward in so many ways !

mortenleth's picture

Hallo gambitj

I would assume that this is a feature.

You speak of Single-Sign-On as if you think it is not present, i do not know if this is infact correct (i might read your words wrong.. :)), but i can assure you that you still have SSO, your just importing things into the solution.
It is still AD which is validating your accounts. :)

When you have imported your groups into SMP you have them listed as roles in your SMP, and afterwards you can put permissions on it, and when you have your permissions in place, you add users to the group in the AD.
You aren't persay managing 2 objects, your setting up your permissions within SMP as you want them to be, which normally is a one time thing, and then after that managing it in the AD.

I know that Symantec has wanted to move away from using NTFS permissions and local groups on the SMP server, to utilize the platform for permission settings instead, that's why i am assuming that this is a feature.

Kind Regards
Morten Leth

Falquian's picture

Hi, Morten:

If I understand correctly your words, you say that once you have imported an AD group into a Symantec role, and when you assign permissions to that role, just by adding a new AD user to the AD Group (without creating a importing an Symantec account for that AD user account), the user will get the permissions inherited by the Symantec role. It would really great if anyone could confirm this.

At the end, this was how security working in 6.0, wasn't it? The difference is that, if my assumption is right, now you don't need to create local gropus in the server were SMP is installed...which may be good.

What I don't understand is why (again, if my assumption is right), when importing users and roles from AD, you MUST import all the users that are members of the AD group into Symantec accounts. I really think that creating a Symantec account linked to an AD group would help a lot. I see no sense in having to create hundreds of accounts, mirroring the AD accounts.

Regards:

      Falquian

Kind regards:

     Falquian

If this post is useful to you, remember to mark it as a solution ;)

mortenleth's picture

Hallo Falquian

I just did it yesterday in my demo environment. :)
It might help if i talk a bit about the steps needed to do this.

1. Create your Active Directory group, i called mine "Symantec Admins".
2. You create an import rule, this import rule is an import "roles and users" rule, which is a new import ability. (this is not something which is available in the past), this rule you configure to import the content of the "Symantec Admins" group.
3. After you have this group imported you under your security have a new role which is called "SMP\Symantec Admins" this group i made a member of "Symantec Administrators", i of course could also have given this group different permission but what i wanted to accomplish was simply to make some users admins.
4. Now every time i add a users to this group, i of course need to run my import again, but creating a schedule for this to run is the right way to do it, and then i don't need to think of anything else.
5. When my users now get imported to the solution i can see them all under "Accounts" tab within security configuration.

So to sum up the bottum line, you create and manage your groups and users within your AD, and you manage what permissions it needs within the solution, the need to create local groups and users locally is now gone.

Your final question tho i must admit i don't really understand, i would only create NEW groups which only is used for this, therefore i don't see a problem in having every accounts within the group imported.

One thing i definently would NOT do and would NOT advise is to import "Domain users" and give permissions to that.

I hope this clerified it for you Falquian :)

Kind Regards
Morten Leth

Falquian's picture

Thanks for the clarification, Morten.

So my assumption was wrong :(

You need to keep the "syncronization" between AD and Symantec.

Now it's clear how this option of the AD import works.

Thanks a lot, Morten

 

Regards:

         Falquian

Kind regards:

     Falquian

If this post is useful to you, remember to mark it as a solution ;)