2012 and Always on - different security access?

  • Here is what I would like to do and wanted to know if possible.

    With always on, have one active node for production applications, one node for reporting with different logins permitted, and one node for backups.

    Is it possible to have a different set of logins per node?

    I am trying to sell 2012 to where I work and one thing we are looking at is using transactional replication in 2008 R2 or go to always on in 2012. Just depends on the security options.

    Thank you.

    Kameron

  • I haven't tried it, but I believe you can. You'll have to live with orphans, because all the users have to be in every database (they're copies), but you could have the logins disabled or not added to the instance levels.

  • khott (7/3/2013)


    Here is what I would like to do and wanted to know if possible.

    With always on, have one active node for production applications, one node for reporting with different logins permitted, and one node for backups.

    Is it possible to have a different set of logins per node?

    I am trying to sell 2012 to where I work and one thing we are looking at is using transactional replication in 2008 R2 or go to always on in 2012. Just depends on the security options.

    Thank you.

    Kameron

    Yes, althought the nodes are a member of the same windows cluster, they are essentially separate instances so logins can be set up differently. Will you be employing any read only routing for your availability group?

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

  • Yes, the other nodes will be read only for the users. Thank you for this information. I will try it out and see what happens then.

  • The one's that are essentially log shipped are going to be tougher, because you can't modify the database target in any way. The ones that are mirrored are somewhat easier, but I am pretty sure security changes on the source will be propagated to the mirror.

    I think Perry is on to something with what logins are present on the server. If you are using AD accounts or groups you it would be easier. For SQL logins you would need to make sure that SIDs on the other servers match up otherwise the security won't flow.

    Interesting idea..

    CEWII

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply